In that case you might try NTFSDisableLastAccessUpdate. http://www.hkeyusers.com/hyper-v-best-practices-ntfsdisablelastaccessupdate/
According to this it's already disabled in Vista and Windows server 2008 http://technet.microsoft.com/en-us/library/cc959914.aspx "Determines whether NTFS updates the last-access timestamp on each directory when it lists the directories on an NTFS volume. This entry is designed to prevent the NTFS log buffer in physical memory from becoming filled with timestamp update records. If you have an NTFS volume with a very large number of directories (in excess of 70,000), and Windows 2000 does not respond quickly to dir commands, adding this entry to the registry might make directories list faster." http://technet.microsoft.com/en-us/library/cc758569(WS.10).aspx "Specifies whether NTFS updates the last-accessed timestamp of a file when that file is opened. Because updating the last-accessed timestamp requires writing data to the disk, an activity that accesses many files might be faster if this type of update is disabled. However, some applications may require that files have an accurate last-accessed timestamp." I seem to remember setting it did improve folder listings of large folders. Ymmv Regards Rene On Tue, Sep 6, 2011 at 7:38 PM, David Lum <[email protected]> wrote: > 2003 Server, 32-bit**** > > ** ** > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Tuesday, September 06, 2011 10:32 AM > > *To:* NT System Admin Issues > *Subject:* Re: # of files on Windows server, is 4 million too many?**** > > ** ** > > What OS, btw? > **** > > *ASB***** > > *http://XeeMe.com/AndrewBaker***** > > *Harnessing the Advantages of Technology for the SMB market…***** > > > > **** > > On Tue, Sep 6, 2011 at 1:15 PM, David Lum <[email protected]> wrote:**** > > Here’s the results from a single logical (SAN) drive on one of our file > servers: > Total Files Listed:**** > > 4661023 File(s) 681,427,607,680 bytes**** > > **** > > On this logical drive are our primary shares for users and shared data, but > if no single folder has more than 2000 files does it matter? I’m thinking > still yes.**** > > **** > > And yes, it takes FOREVER to do any kid of file maintenance on this. **** > > **** > > Dave**** > > **** > > **** > > *From:* Michael B. Smith [mailto:[email protected]] > *Sent:* Tuesday, September 06, 2011 8:57 AM > *To:* NT System Admin Issues > *Subject:* RE: # of files on Windows server**** > > **** > > Consider this: NTFS is a type of database. And not a very efficient one > either. And, for very small files, the files are actually stored within the > file system, while with larger files, NTFS has pointers to the actual file > data stored in the FS.**** > > **** > > Storage size has exploded in the last 10 years. However, performance has > not matched the size expansion.**** > > **** > > If I’m going to simply OPEN or CREATE a small file – number of files has > little impact. NTFS is just going to create a new entry in the database.** > ** > > **** > > If I need to find, list, or extend a file – well, it’s going to take > longer.**** > > **** > > If I need to enumerate files (that is, get a directory listing) the more > files I’ve got, the longer it’s going to take.**** > > **** > > It “can be shown” that having more than about 1K files in a directory will > effect enumeration. It becomes really noticeable (IMHO) around 10K and heads > rapidly downhill after that.**** > > **** > > Regards,**** > > **** > > Michael B. Smith**** > > Consultant and Exchange MVP**** > > http://TheEssentialExchange.com**** > > **** > > *From:* David Lum [mailto:[email protected]] > *Sent:* Tuesday, September 06, 2011 11:46 AM > *To:* NT System Admin Issues > *Subject:* # of files on Windows server**** > > **** > > Recently we had a thread about how many files get to be too many for > reasonable performance. Would this be just per folder, or possibly logical > drive in general? Links/documents would work too.**** > > *David Lum* > Systems Engineer // NWEATM > Office 503.548.5229 //* *Cell (voice/text) 503.267.9764**** > > **** > > ** ** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin**** > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
