Las Solanas Consulting

Storage Virtualization | FAQs & Discussions

Last Access And Shared Storage - A Simple But Effective Performance Tweak

A White Paper by Tim Warden, June 1, 2008


Some time ago, I discovered a minor annoyance with the NTFS file system on Windows machines. My fileserver uses SANmelody multi-path mirrored virtual volumes for the fileshares. I use SANmelody Thin Provisioned Snapshots to give me a rollback point in case I accidentally delete something. I noticed that over time the thin-provisioned snapshot volume was growing, even though I wasn't modifying anything on the source volume. With a bit of investigation, I noticed that whenever I would copy files from the file share, or even just browse the folders of the fileshare, Thin Provisioned storage was allocated on the corresponding snapshot volume. This would indicate that even though I was only reading the volume, something was causing writes to the volume, my snapshot source.

I asked one of the DataCore software engineers if he knew why I was getting these unexpected writes. He advised me to try the NT Resource Kit's Filemon and Diskmon utilities to see what was up. As it turns out, every time I accessed a file, a "SET INFORMATION" was showing up in Filemon, which corresponded to a WRITE in Diskmon. It occurred to me that the write was most likely caused by updates to the "Last Accessed" timestamp in the NTFS file system.

I don't know about you, but I've never found any good use for that "Last Accessed" timestamp. It seems like it would be good for security monitoring or forensics, but anytime I've opened the "Properties" dialog on a file, the "GET INFORMATION" call accesses the file, and so the file's "Last Accessed" field immediately gets updated showing the current date and time, which seems to defeat the purpose. Oh, I suppose I could call "DIR /TA" from the command line (which doesn't "touch" the files, although it does touch the directory), but it's not an imperative that I know when files were last touched as long as I can at least know when they were last modified.

More importantly, those Last Access updates increase "write" traffic to the disk, which ultimately impedes performance, particularly when RAID5 is in use. When taken in the context of a SAN environment with many Windows servers, these "Last Access" updates can generate a lot of superfluous write traffic, which can have some less than obvious consequences.


I've already pointed out one such consequence as relates to thin provisioned snapshots: the "Copy On Write" mechanism employed by most SAN vendors's snapshot implementations will need to copy over "chunks" from the source to the snapshot area each time a file is first accessed or "touched", needlessly using additional storage from the Thin Provisioned Storage Pool.

But those Last Access writes also create an additional lag on performance with snapshots because each "copy on write" operation will result in a read and two writes on the snapshot relationship — and again, using RAID5 will only exacerbate the snapshot write penalty.


In Virtual Server environments such as Citrix XenServer, Virtual Iron, or VMWare ESX, the Last Access timestamp updates on NTFS virtual machine disks (e.g. VHD or VMDK files) can impose performance degradation beyond the simple expected write penalty on the datastore. SCSI Reservations are used to implement XenMotion, LiveMigrate, VMotion or any clustered filesystem to decide which physical host gets to write the shared LUN at any given instant. These additional Last Access writes will simply increase the likelihood of contention on the shared resource; the potential increase in SCSI Reservation conflicts would result in decreased performance.

As those writes clearly turn into changes on the associated vm disk file, they will accordingly increase the workload and backup file sizes of your vm backup system (e.g. vRanger Pro). Worse still, if you are using or abusing a filesystem snapshot mechanism (like VMware snapshots), the Last Access writes will cause the snapshot file to grow needlessly.


Finally, the writes associated with Last Access timestamp updates can have a negative impact on bandwidth utilization and overall performance in synchronous and asynchronous mirroring.

In Synchronous Mirroring (used in Business Continuity), the Last Access writes will be faithfully mirrored between the primary and secondary volumes, consuming a small increment of bandwidth and adding latency — particularly if write cache on the mirror is in a "pending" state, waiting on a cache flush to complete.

As for Asynchronous Replication, many shops have bandwidth limited to T1 speeds; Last Access writes occurring on replicated volumes simply add additional superfluous traffic over the inter-site link.


As it turns out, there's a simple solution to the Last Access annoyance.

Recently I decided to perform an internet search (notice how I avoided using the brand-name "Google" as a verb? :-) to see if there was a way to disable "Last Access" timestamp updates in NTFS. And sure enough, Microsoft has a Knowledge Base article on the subject:

Disabling Last Access Time Stamps is as simple as adding a registry key in RegEdit, as documented in the following table.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Name: NtfsDisableLastAccessUpdate
Value: 1

That's all there is to it — I had to reboot the server in order for the registry change to take affect.

RegEdit ScreenshotAdding the Registry Key


On my SANmelody and SANsymphony servers, I disabled the Last Access timestamp updates to improve AIM performance. Last Access writes add needless overhead when the AIM Source or Destination services access AIM files as well as when the AIM transport mechanism (CIFS or FTP) accesses them.

In Traveller nodes, the Last Access timestamp updates can degrade performance when reading volume journal files to generate Rollback Volumes.

Finally, in SANharmony or any other Windows-based NAS server, disabling the Last Access timestamp updates will improve CIFS / NFS performance by reducing spurious writes to the shares as users access their files.


I've implemented this in my lab and it's working fine. However, before you take my advice and make this 2-minute tweak on your Windows servers, you should do your own research to assure that none of your applications or processes rely on the Last Access timestamp. For instance, some backup software packages may use the value, perhaps to determine if they need to traverse a branch on incremental or differential backups.


Las Solanas Consulting is not a DataCore™ reseller. The opinions expressed herein are entirely those of the author and in no way should be misconstrued so as to represent those of DataCore Software Corporation.

For more information, please contact DataCore™ or one of DataCore's Authorized Resellers.