Jump to content

Improve NTFS performance


ɹəuəllıʍ ʇɐb
 Share

Recommended Posts

Have you tried it, Pat?

Does it do what it claims?

Done it today. I have an application that run 24*7 and does lots of I/O. I will know in a few days if it has become any faster.

But it makes perfect sense. Applications that only read data (searches, anti-malware scans, etc.) will all issue a write to every file they access. Eliminating that "unnecessary" write will definitely make such scans faster.

Also, since such scans touch mostly all files on the system, the "last access" date means perfectly nothing. It might be interesting to know when you have last accessed a certain document, but every scan will overwrite this information.

Link to comment
Share on other sites

Backups, such as Acronis incremental or differential backup, will look at the modified date rather than the last access date. So I don't think it will affect backups in any way.

It will, however, affect archive software that archives files that haven't been used in a certain period. But that is used mostly in a corporate environment, e.g. on server-type machines.

Link to comment
Share on other sites

Can't try it unfortunately, I have XP Home. :D

There is another comment under the original article that explains how to change it for XP Home users (registry hack):

There are two possibilities for the Home Edition: (but only, if you trust yourself to edit the registry)

1. Start, Run and type Regedit:navigate to:

HKEY CURRENT USER/Software/Microsoft/Windows/CurrentVersion/Policies/Explorer:

Rightclick in the right column, choose New,

then Dword-value and name it: NoInstrumentation, doubleclick on it and give it a value 1, close and restart.

2. Start, Run and type Regedit: navigate to:

HKEY LOCAL MACHINE/System/CurrentControlSet/Control/FileSystem:

Rightclick in the right column, choose New,

then Dword-value and name it:

NtfsDisableLastAccessUpdate, doubleclick on it and give it a value 1, close and restart.

Lots of success!

Link to comment
Share on other sites

Can't try it unfortunately, I have XP Home. :D
There is another comment under the original article that explains how to change it for XP Home users (registry hack):
There are two possibilities for the Home Edition: (but only, if you trust yourself to edit the registry)
My OS is XP Home.

I don't have any experience of the registry, so I tend to leave it well alone.

Also, since I am an 'at home user' now, it is not an essential for me. :)

Link to comment
Share on other sites

Can't try it unfortunately, I have XP Home. :D
There is another comment under the original article that explains how to change it for XP Home users (registry hack):
There are two possibilities for the Home Edition: (but only, if you trust yourself to edit the registry)
My OS is XP Home.

I don't have any experience of the registry, so I tend to leave it well alone.

Also, since I am an 'at home user' now, it is not an essential for me. :)

That is really wicked doing that to a poor old man. :D

Link to comment
Share on other sites

So far I have not seen any proof that anything is any faster.

I am still convinced that searches, scans, indexing, may be faster than before. However, there is no data to proof it.

But I am going to keep the setting, as I have no real need for the last-access timestamp.

Link to comment
Share on other sites

  • 4 months later...

In addition to NOT updating the last accessed stamp in the MFT$, per this article's "tip" (long known since 1997 or so in fact)?

    1.) There is also the ability on NTFS to disable 8.3 naming convention (for older DOS & Win3.x programs backwards compatibility, & if you don't NEED that (since your apps are probably MUCH newer & 254 character long filename capable is why)) also...

    2.) PLUS, there is also the ability to disable paging the OS core kernel component subsystem's memory to the pagefile.sys, to increase the OS core component's subsystems' performance (& to lessen disk I/O to where your pagefile.sys is located, which by default/usually, is your C: main disk & where your OS & Programs also typically lay as well - the less paging that goes on there, the faster your OS &/or apps function too).

* Think about using those features as well - there ARE possible gains to be made by turning those off from my list above also (every little bit adds up & helps in other words).

(Point #2 also sort of leads into WHY (on the no paging OS executive subsystems memory back & forth to pagefile.sys on disk) folks MOVE their pagefile.sys to another HDD (if they have more than 1 harddisk drive that is)... so paging ops do not interfere with programs & data loading (or less of it rather interfering with that task, initializing programs)).

APK

P.S.=> I.E./E.G. (this .reg file content, if copied from between the equal sign lines, when inserted into notepad.exe & saved as a .reg file type + later merged (via double-click on the file in MyComputer OR Explorer.exe filemanager), SHOULD cover literally nearly ALL of the bases for increasing NTFS performance)->

=================================

Windows Registry Editor Version 5.00

;-----------------------------------------------------

; For Windows NT/9x use below instead of above line

;-----------------------------------------------------

;REGEDIT 4

;-----------------------------------------------------

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]

"NtfsDisable8dot3NameCreation"=dword:00000001

"Win31FileSystem"=dword:00000000

"Win95TruncatedExtensions"=dword:00000001

"AsyncFileCommit"=hex:01

"ContigFileAllocSize"=dword:00001000

"NtfsEncryptionService"="Efs"

"ReadAheadThreshold"=hex:00,00,20,00

"NameCache"=hex:00,18,00,00

"PathCache"=hex:80,00,00,00

"DisableLastAccessUpdate"=dword:00000001

"DisablePagingExecutive"=dword:00000001

"NtfsDisableLastAccessUpdate"=dword:00000001

"Disable8dot3NameCreation"=dword:00000001

=================================

apk

Link to comment
Share on other sites

This can also help:

LASTLY, to help improve ANY type of filesystem & disk performance? Move EventLogs (& other forms of logging I/O from other apps you use) to another HDD (along the lines of moving pagefile.sys to a 2nd less used HDD really):

--------------------------------------------

MOVING EVENTLOG FILES TO OTHER DISK (less frag + I/O & gain speed), Gain speed lessening the burden on the MAIN C: drive for eventlogs (& other forms of logging)

http://forums.pcpitstop.com/index.php?showtopic=152970

--------------------------------------------

APK

Link to comment
Share on other sites

2.) PLUS, there is also the ability to disable paging the OS core kernel component subsystem's memory to the pagefile.sys, to increase the OS core component's subsystems' performance (& to lessen disk I/O to where your pagefile.sys is located, which by default/usually, is your C: main disk & where your OS & Programs also typically lay as well - the less paging that goes on there, the faster your OS &/or apps function too).

This may seriously (negatively) impact user applications if the system is short on RAM. Not all of Windows' subsystems are always required, so they can be safely paged out without any noticeable effect.

Link to comment
Share on other sites

2.) PLUS, there is also the ability to disable paging the OS core kernel component subsystem's memory to the pagefile.sys, to increase the OS core component's subsystems' performance (& to lessen disk I/O to where your pagefile.sys is located, which by default/usually, is your C: main disk & where your OS & Programs also typically lay as well - the less paging that goes on there, the faster your OS &/or apps function too).

This may seriously (negatively) impact user applications if the system is short on RAM. Not all of Windows' subsystems are always required, so they can be safely paged out without any noticeable effect.

Conversely, by PAGING said "core OS kernel subsystems portions", you could INDUCE paging & thus, impact performance also... it's a trade-off that'd be, imo @ least, dependent on the application mix &/or use-patterms of the user (as well as his memory amount he has in his system in actual physical RAM chips).

I run on 512mb of DDR-400 SDRAM, & have this "tweak" in place, on Windows Server 2003 SP#2 fully hotfix patched as of this date today... no hassles!

(QUESTION: Do you have any supporting/documented evidence of the "performance hit" you speak of, actually happening? If so, I'd like to read about it/see it... thanks!)

:)

* Here? I run a pretty decently varied "mix" of apps as well (from typical end-user productivity apps like Ms-Office 2003, thru your typical blend of web apps like browsers & email etc., all the way thru to Visual Studio 2005 & Borland Delphi 7.x also... & w/ this very 'tweak' in place, I have yet to see "hassles" due to say, "out of memory" type conditions &/or even severe "lag".

APK

P.S.=> Speaking from my OWN experience only, I haven't seen a "bad performance impact" as a result of applying this 'tweak', but, then again - I also "trim off" services &/or background trayicon minimized apps that used to run here all the time as well (& I quite literally wrote the FIRST GUIDE ONLINE for it as "Article #1" for NTCompatible.com (from early 1998 when that website came online))!

Thus, perhaps, this is HOW I am "making up for" the application of this tweak AND on a system with "ONLY 512mb of RAM" in place...

HOWEVER/Disclaimer:

In addition to my tuning my system vs. services & such I do NOT need - I am also running a 2gb SOLID-STATE DISK (1 partition = logging from apps & OS, webbrowser cache, command interpreter location (cmd.exe), %temp/tmp% environment variable location, HOSTS file location, & more... this MAY help offset latency on my C: drive by removing those "burdens/tasks" to its 1st partition... the 2nd partition is my PAGEFILE.SYS location (1gb to itself)) & this imo?

This type of setup (noted above in last paragraph) would be the LARGEST offset to possible/potential performance detriment I might have here because of THIS tweak &/or others (because when & IF I page? It happens MUCH FASTER than it would on a std. HDD, by it now taking place here instead on a SSD)...

Anyhow/Anyways- To each his own! apk

Link to comment
Share on other sites

MORE TIPS ON "IMPROVING NTFS PERFORMANCE":

In this post, I'll cover things that work to improve NTFS performance even further than Pat W. has noted here, or myself & others later... things like:

    A.) Directory Consolidations (HOW TO, automatically OR manually)

    B.) Determination of "ideal" CLUSTER SIZE to use when formatting, for performance gains.

    C.) MFT$ Reserved Zone control (to avoid fragmentation of the MFT/Master File Table)

    D.) Use SHORT filenames AND directory names (shorter strings to parse, make for shorter processing times, albeit @ the cost of good 254 character long filenames/foldernames (trade-off))

    E.) The benefits of the usage of NTFS compression for READS (which does eat MORE CPU cycles (but, far less than years past, because of the speed of today's CPU's &/or RAM for processing - helps on READS, which is MOST OF WHAT YOU DO odds are, vs. WRITES to disk (smaller filesize reads up off disk, faster, but incurs larger performance hits on WRITES (keep this point in mind))

(HOWEVER, @ times, some of these "tips/tricks/techniques" DO, or CAN, demand you have particular softwares (such as defraggers to make it easier, where I mention them, because there ARE "manual drudgery methods" of achieving the SAME EFFECT (Directory Consolidations, via copy/move files from 1 harddisk to another harddisk, temporarily, to achieve that)).

Here we go:

----

    DIRECTORY CONSOLIDATIONS (HOW TO ACHIEVE IT - AUTOMATICALLY via programs, OR, even "manually"):

Products like Executive Software's DISKEEPER, Raxco's PERFECTDISK (best one, imo @ least), & even iirc, O&O Defrag can achieve this @ boottime!

(& on Windows 2000, when using Norton Speedisk? It CAN do this during normal usermode/Ring 3/RPL 3 mode of operations (only on Windows 2000 though, because afaik & understand, from talking in the past w/ G. Hayes of RAXCO? The underlying "MoveFile" API extension done jointly by Executive Software & Microsoft takes over even in Norton Speedisk on XP/Server 2003 & future MS OS'... whereas on NTFS filesystems on Windows 2000, it still can & does use Norton/Symantec's PROPRIETARY filemove API, which allows greater uptime (no reboot) during directory consolidations!))

The less fragmented they are, the FASTER THEY ACCESS (read up from disk & write too, due to less head movements)... just like any other file (because that's all directories, or really ANYTHING in most modern OS is: A file, one you open/read-write/close, & this includes things like screen or other device contexts too)... it's ALL files.

Now, I shouldn't even "bloat" this post with this, but... if you don't have one of those 3rd party superior defraggers (superior, as opposed to the Microsoft native defragger)? You CAN achieve this, albeit manually, & it's a lot slower + more of a pain to achieve... it's done by:

A.) COPY ALL OF YOUR FILES TO ANOTHER DISKDRIVE (be it HDD, DvD-RW, etc.)

B.) DELETE THE ORIGINAL PARTITION/DISKS' FILES (ONCE MOVED/BACKED UP AS INDICATED IN STEP "A" ABOVE - BUT, not the folders/directories)

C.) COPY THE FOLDERS/DIRECTORIES TO ANOTHER DISKDRIVE (again, any type you have that is large enough to contain them)

D.) DELETE THE ORIGINAL PARTITION/DISKS' DIRECTORIES-FOLDERS

E.) OPTIONAL: IF You only have 1 HDD (harddisk drive)? Create your pagefile.sys on it now (Via Control Panel-> System Icon etc. (performance/advanced tabs & buttons areas here) - otherwise, moving your pagefile.sys to another HDD is advised for the BEST performace (especially from your "main C: drive" (usually C: is the default system diskdrive letter where the OS &/or Programs you use typically operate from)

F.) NOW, FINALLY? COPY BACK YOUR FOLDERS & DIRECTORIES TO THE ORIGINAL DISK YOU ARE DOING THIS ALL TO! They will now techically copy in right behind pagefile.sys (if you located it on the same disk that is, see last step) & MFT$, in CONTIGUOUS UNFRAGMENTED ORDER & STATE) then, copy your files back into their folders & DEFRAG THE DRIVE!

* Believe-it-or-not? That works... & shows you all the "madness-N-lunacy" a disk defragger has to go thru to achieve directory consolidations (minus using other HDD's no less & via arrays/buffers in RAM & temp files on disk no doubt, to do so)...

----

    Determination of "ideal" CLUSTER SIZE to use when formatting

THIS, can be a "bit of a pain" to do, but it's worth it!

chkdsk can help here, OR, Executive Software's DISKEEPER Program, by showing you average filesize (which Diskeeper's reports DO yield), OR via chkdsk & doing this calculation:

TOTAL KILOBYTES USED DIVIDED BY THE TOTAL # OF FILES ON DISK (This isn't the 'greatest way' to do this, but better than nothing & especially IF you don't own tools like Diskeeper).

(Then, when you're ready, you can use the diskmgmt.msc tool to format a new disk & choose its clustersize there, OR, use the DOS prompt FORMAT command (with switches on its commandline)):

E.G.-> FORMAT [drive letter insert here]: /FS:NTFS /A:[clustersize you chose]

(CLUSTERSIZE PARAMETER OPTIONS = 512 byte (default, very efficient vs. clusterslack loss of diskspace, but not great @ performance (trade off)), 1024kb, 2048kb, 4096kb, 8192kb, 16384kb, 32768kb, OR even 65535.64kb max.)

IMPORTANT NOTE:

Afaik - YOU CANNOT format your main disk (driveletter C: by default on MS OS' typically) this way, for your booting disk (where the OS typical installs to unless otherwise instructed)

OR,

You cannot even use the CONVERT command in a DOS prompt to do so for your bootup disk...

I.E.-> The Microsoft Windows NT-based family of OS' will NOT bootup from anything other than the default 512 byte sized clustersize formatted default (unless anyone here can tell me differently that is, that's been my experience over time, in trying to format 4kb sized ones for a bootdrive/maindisk C: - I could NEVER get it to work & too bad - it'd most likely yield performance gains on the MAIN C: disk too, like it does for others, once you find the "ideal size" for cluster sizes (to avoid clusterslack, 512 byte is best OR the use of NTFS Compression, but for performance, unless you have ALL super-tiny sub-512 byte files, which you don't? Larger sized clusters help, for performance' sake!)...

Personally, due to the "average filesize" (not really averages, these CAN be deceiving even IF you go thru every file & do the avg. via math, & without weighting the occurances of various filesizes) I have here? I go with 4,096 byte/4kb sized clusters, which incidentally matches the size used by the memory mgt. subsystem in paging to & from disk as well to the pagefile.sys... however, here's how you go about this:

A "good rule of thumb" here, is simple:

Based on the above - know your typical filesizes on disk (& if in the case of a storage drive where you stash HUGE files? Go as high as clustersize allows for faster performance (albeit, more possible clusterslack (loss of diskspace due to filesystem physics constraints vs. actual physical diskspace possible) OR, just "DO THE MATH" via the calculations I noted above (or, just use a good defragger like Diskeeper for its reports in THIS regards, which IS easier IF you own it)).

----

    MFT$ Reserved Zone control (to avoid fragmentation of the MFT/Master File Table)

This ONLY WORKS, in a registry hack to the filesystem driver parameterizations, PRIOR to formatting a disk (it won't take effect on disks already formatted, so you WILL have to format to get this gain:

The reason this is noted, is you do NOT want it fragmenting (& thank goodness modern defraggers like Raxco PERFECTDISK & ExecSoft's DISKEEPER can make this a "non-issue" because unlike the native defragger (last I knew of @ least) that comes with Windows NT4.0 (after SP#4 for it that is)/2000/XP/Server 2003 & VISTA? They CAN defrag the MFT$ (your "master file table").

Here is the .reg hack to the registry that helps reserve extra space for the MFT$ (use regedit.exe to set this & then, format a new disk to take advantage of it (good for storage drives & their performance):

HKEY_LOCAL_MACHINE -> SYSTEM -> CURRENT CONTROL SET -> CONTROL -> FILESYSTEM

Once there, you can set this value:

NtfsMftZoneReservation

in a range from 1 - 4 (1= 12.5%, 2 = 25%, 3 = 37.5%, & 4 = 50% of the total volume space)... the default's 1 by the by.

The problem with fragmentation of ANY KIND, is a problem with NTFS (I note others I have discovered over time in my P.S., a far more "insidious" one no less) is that fragmention of files, folders/directories, OR THE MFT$ itself, can still literally HALT an NT-based OS (even though it is largely 'fragmentation resistant', moreso than FAT16/Fat32, it still frags nonetheless)...

Remember though - the MORE you allocate to this MFT reservations zone, it doesn't take away space from most files you'll be storing (small ones especially, because some files like tiny ones, often exist IN THE MFT$ & its associated files, inside of them no less & will store them there vs. userspace on disk (especially if its low & the files are smallish))

----

    Use SHORT filenames AND directory names (shorter strings to parse, make for shorter processing times, albeit @ the cost of good super-descriptive 254 character long filenames/foldernames (trade-off))

Self-explanatory, read what is in parenthesis about shorter strings to parse in file & folder/directory names = less work for filesystem drivers in essence)

----

    The benefits of the usage of NTFS compression (for READ performance)

NTFS compression does eat MORE CPU cycles during its decompression stage in RAM, even on READS of data up from disk into memory (but, far less than years past, because of the speed of today's CPU's &/or RAM for processing - helps on READS, which is MOST OF WHAT YOU DO odds are READS, vs. WRITES to disk!

(OVERALL - This WILL gain read performance here since files are smaller on disk (& the decompression stage is offset by today's FAR faster CPU's & RAM)... they are smaller & thus, pickup F A S T E R (however, conversely, WRITES you perform will be a LOT slower, due to the user of NTFS compression)... now, most folks do FAR MORE READING than WRITING, to disk, so most folks can make a "gain" here by using NTFS compression, in the long haul (believe-it-or-not))...

----

* Whew, FINALLY done... lotta writing, but, enjoy (that's ALL I KNOW on how to "boost NTFS performance", between this post & my previous 2 posts before this one)...

APK

P.S.=> Now, is NTFS "perfect"? No... because, in addition to some points I made above?? It has some "holes" & imo, a single SERIOUS one:

In fact, if you were to say, create a timed task (or executable, OR EVEN VIRUS that does this below), that creates 0 byte sized files @ HIGH SPEED in a loop? You'd think (probably initially @ least) "they take up no space & thus cannot adversely affect me eating up all my disk space OR creating/aiding in fragmenting other files" but...

That's NOT TRUE - Because, eventually, your MFT$ still accounts for them & so do the "meta data" areas of the filesystem in NTFS... create enough of these "0 byte sized files" & YOU CAN FLOOD OUT YOUR DISK EVENTUALLY, via MFT$ bloat!

I theorized a virus/malware/spyware that might do this, a decade ago, & am GLAD one has not surfaced that used this "heinous machination technique" as I call it... because it would fool a LOT of things & blow your disk eventually by eating up all of the space it has, albeit via the MFT$ itself (which NEVER, ever shrinks, mind you... this also leads to the possibility also of opening it, & reading any + EVERY file you ever had online (sometimes? That's "not good" for security, vs. forensics type analysis is all I can say about that (think about it))... apk

Link to comment
Share on other sites

Whoops! 1 more thing that can help BOTH Filesystem Driver AND Disk Driver (plus, physical disk performance), but, it's kind of a 'cheap trick':

"SHORT-STROKING" a DISKDRIVE (what is it, how is it done, etc.):

When you partition a disk, you can do the "whole thing @ once/enmasse", OR, cut it into partitions with logical drive letters assigned... many folks do this for various reasons, but, there is a "hidden in plain sight" gain possible (albeit, @ the expense of diskspace)... read on:

When you do a "short-stroke" partitioning of a disk, you only PARTITION say, HALF OF IT... why?

Because of physics!

The outermost tracks of a disk have greater circumference/diameter (et al), & thus, they HAVE FASTER TRANSFERRAL RATES THAN A DISKS INNER TRACKS DO!

(& when you initially partition & format your disks, the outermost faster tracks get done, FIRST!)

:)

* By this point, I think you know where I am going with this... it IS a "cheap trick", BUT, one that works on the SAME PRINCIPAL as when you use 18-21" rims on a car, vs. 17" & below... larger diameters lead to faster performance!

(However/Again - It's one that MIGHT cost you diskspace no less, should you choose to implement it... diskdrive makers have used this trick in the past, believe it or not, to make their disks seem to perform FASTER than they are on the whole area they possess & on benchmarks - pretty dirty, but not nessarily "lying" either (just not telling ALL of the truth, lol!))

Still - on a std. electro-mechanical HDD (harddisk drive), this actually WORKS...

(& iirc, this does NOT "hold true" on Solid-State disks (because they are NOT 'circular' in design, so you know - I have one here, & thus, am mentioning it for those of you that MAY also have one (CENATEK RocketDrive here, others are ones like Gigabyte IRAM SATA 150 type... I only consider THESE true SSD's, not the "flash based" stuff that vendors are trying to sell folks, or that MS believes in using in VISTA's new "caching scheme" (which has proven QUITE faulty, especially on multimedia files, copies, & network caching + more, & had to be altered to only TINY gain over the previous (imo, erroneous design of 'commit all free memory to caching') build of VISTA, prior to SP #1))...

Anyway/anyhow - you've now got ALL I KNOW on how to "boost NTFS" & overall filesystem + disk (driver & physical level) performance, short of using better/more enhanced diskcaches (like SuperSpeed.com's "SuperCache II" for instance - look THAT up, if your interested (I helped design parts of it while increasing its performance via tuning by up to 40% over stock settings, circa 1996-1997 (& some of the work in research for its sister program, SuperDisk, took that company to a finalist position @ MS Tech Ed in its hardest category "INCREASING SQL SERVER PERFORMANCE" in both yrs. 2000-2001 iirc, & it works too, but costs)))... apk

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy