NTFS Performance

[Jerry Atrik 0]

back to the original problem... is disk logging active

did u instal ms office's llama find fast?

the 2 together wreak havoc

[ghayes 0]

"If it's @ the beginnning of the partition [howver that's defined] & a fixed size, then it doesn't get in the way of other files."

 

Then by definition, if the pagefile is contiguous any other place on the partition then it is also not in the way of other files

 

 

"Well I use FAT32, & as I already stated I've proven that folders can be sorted whilst windows is running."

 

Using Microsoft's defrag APIs under NT4, Win2k and WinXP - No. Under Win9x/Me - Yes. SpeedDisk under NT4 and Win2k doesn't use Microsoft's defrag APIs and is able to consolidate directories online. Under WinXP, SpeedDisk uses Microsoft's defrag APIs and therefore can't consolidate directories on FATx partitions.

 

- Greg/Raxco Software

[Alien 1]

Quote:

Then by definition, if the pagefile is contiguous any other place on the partition then it is also not in the way of other files

Not necessarily. If the swap file is the only file over about 10MB or so then you'd be right, but if you have some large files, eg video, then it may end up that the defragger decides that the startpoint for a file should be @ a specific point [due to what area it should reside on the HDD because of filetype or last date of access or whatever it's basing it's decisions on for file placement] & that point happens to be less then the file's size away from the beggining of the swap file then you end up with a fragmented file. Basically, having the swap file @ the beginning of the partition/drive means that the defragger [& the file system] doesn't have to work around the swap file.

Surely I can't be the only 1 to see the logic in this?

Quote:

Using Microsoft's defrag APIs under NT4, Win2k and WinXP - No. Under Win9x/Me - Yes. SpeedDisk under NT4 and Win2k doesn't use Microsoft's defrag APIs and is able to consolidate directories online. Under WinXP, SpeedDisk uses Microsoft's defrag APIs and therefore can't consolidate directories on FATx partitions.

Exactly! I never said that what I wanted was a defragger to do what I wanted & to use MS's API - I just said that I wanted them to do it - I don't care how!

[clutch 1]

Alien, his response is simply stating that:

 

A. You are handling the swap file on a logical level rather than on a physical level, so rotational speed will not enhance the I/O of the file by "moving" it anywhere (which you aren't), and

 

B. Having the file in a contiguous state is far more important than fiddle around with the logical location of it.

 

I understand what you are driving at, but from what I have read over the last few years the concept of parking the swap (or any) file on a specific location on a partition is minimal at best, especially considering the I/O of even the slowest systems being released. Personally, I would (and usually do unless an app whines, *cough* Photoshop *cough*) can the swap file anyway if it isn't needed, and not fiddle with it.

[Four and Twenty 0]

ne one who still likes fat 32 hasn't gotten a big hard drive yet

i have an 80 gig and a 120 drive and a 150 gig raid array. You can't make a fat 32 partition over 32 gigs what a friggin joke. NTFS has security. It is the NT File System, FAT32 is really only there for backward compatability.

[Admiral LSD 0]

I wouldn't be at all surprised if it simply disappears in the next version of Windows...

[Jerry Atrik 0]

it outta disappear. how many people here run a min swapfile

just to keep the system happy

[Alien 1]

What's that got to do with what file system you're using?

[packman 0]

Here's my pennyworth. I'm currently making preparations to change my Win2K FAT32 partitions to NTFSs. I've studied a number of detailed books on Win2K and the file systems and these are some of the facts I discovered:

 

1. If you originally had FAT32 partitions and you converted to NTFS by using the Convert command, then you will certainly permanently slow down your hard drive. This is because Convert will leave the Master File Table spread all over your partition, rather than in a neat contiguous block at the beginning. The MFT holds all the information about individual files. Instead, to convert, you should use Format. This also puts a buffer zone next to the MFT, so further reducing fragmentation of the MFT.

 

2. Even with careful formatting, an NTFS partition might not still run as fast as its FAT32 equivalent. You're likely to get slower NTFS operation with smallish hard disk size and where you're using lots of small files (and so the MFT is used that much more).

 

 

Although I've been spending a lot of time planning my conversion, I'm still wondering whether it's going to be worth it. I think the main advantage of NTFS will be in its better file recovery features, slightly better overall reliability, and ability to handle partitions in excess of 32GB. Beyond that, I can't see a really valid reason for using NTFS on a standalone machine.

[DosFreak 2]

There's a program that comes with the OEM Tools that will when run will format your FAT32 partition so that in the future if you decide to convert to NTFS then it will convert to the proper 4KB clustersize instead of the 512b Cluster size. It's pretty neat, also give's people an opportunity to test out both without having to repartition.

[jwl812 0]

I have formatted, reformatted and reformatted again and installed XP on both NTFS and FAT32. FAT32 is noticably faster. Program launch times are less than half. My hardware is a 1.2gh Athlon T-bird, 384mb Ram, VIA KT133 system chipset, Geforce 2 Mx400 video card, 40Gb Quantum Fireball. I have noticed a huge performance difference between FAT32 and NTFS. I ran some HDD benchmarks on both files systems and NTFS cant come close to FAT32. I hate to say it but NTFS ain't all that. Just because M$ says it better doesnt mean a thing to me. NTFS runs like shite on my machine. FAT32 screams and I never had a problem on my older Windows 9X machines using FAT32. Its a tried and true system that has never failed me before. When or if FAT32 screws me then I will switch. Thanks for everyones input.

[DosFreak 2]

As stated by Hat Monster on www.arstechnica.com :

 

Quote:

You want to go from a modern, hard linking, journalling, secure and reliable file system to an FS that routinely loses data, is a clumsy extension of a fifteen year old dinosaur, has no security to speak of and performs directory operations like it's on a PIO-0 1,100RPM hard disk?

 

 

Your choice of course.

[packman 0]

It's all very well you lot criticising jwl812 and producing quotes of one sort or another, but not one of you has produced a shred of evidence that NTFS is at least as fast as FAT32, or is only marginally slower. Could that be because jwl812 is actually correct in his/her assertion? If not, then what do you suppose jwl812 has or hasn't done, to have made his/her system so slow?

 

It's certainly true that M$ plays down the speed aspect of NTFS, in preference to promoting its security and recovery aspects. I guess also that, with some respondants, there's an element of "I'm not going to admit I didn't necessarily make the best choice". You get that with all sorts of products and services, not just computers.

 

For me, maintaining decent speed of operation is all-important (and no, I'm not a games person), so if it comes down to a choice between speed and security/recovery, I'll go for the former. To date, my FAT32 partitions have worked almost flawlessly; on the few occasions when a program's halted, Win2K has always recovered the situation without, apparently, any longterm damage. So, perhaps the argument for NTFS, rather than FAT32, is not as clearcut as one would at first suppose.

[Brian Frank 0]

Could be something with their hardware. I for one have tested FAT32 and later went on to NTFS. I'd love to say I could tell you a difference, but I can't, at least not in real life.

[packman 0]

Ah, perhaps the truth is now slowly beginning to emerge. Perhaps jwl812 really DOES have a point?

 

I'll personally stick with the alleged better speed of FAT32, unless and until such time that someone can demonstrate convincing evidence to the contrary. Thanks, jwl812, for causing me to think twice about NTFS. It's not always best to go with the crowd, eh?

 

Sure, if you're a commercial outfit, your leanings are probably going to be more toward the reliability/security side of things.

[Admiral LSD 0]

I'll admit, FAT32 has always been noticably faster than NTFS on my boxes yet, I still format my partitions as NTFS. Why? As well as the reason I mentioned earlier I'm also a firm believer in NTFS's ability to keep my data safe. Nothing hits that home to you like having a complete hard disk meltdown and being able to get every single one of your important files off the disk.

[clutch 1]

Wow, I guess I should have checked back a while ago, but this comparison (FAT/FAT32/NTFS) normally comes up about once every 6 months or so (we have been overdue for a while), so I'll break out one of my fav links on the subject:

 

http://www.microsoft.com/technet/treevie...rt3/proch17.asp

 

Now, here's a nice quote on it:

 

Quote:

Performance

For small volumes, FAT16 or FAT32 might provide nominally faster access to files than NTFS because:

 

The FAT structure is simpler.

The FAT folder size is smaller for an equal number of files.

FAT has no controls regulating whether a user can access a file or a folder; therefore, the system does not have to check that a user has access permissions to a file or folder. This advantage is minimal, however, because Windows 2000 still must determine whether the file is read-only, or whether the file is on a FAT or NTFS volume.

 

If this doesn't help, I think I have some more links buried somewhere to help illustrate the performance a bit more, but essentially what you are looking at is a great big virtual tile floor. Now, since the tile floor (the partition) is of a fixed size, the smaller the tile you use will gain you more open spots for more tiles right? Well, on larger partitions (let's say >8GB, since that's average) FAT32 will have a much larger "cluster" (tile) size than NTFS (and less security overhead, however the MFT performance offsets most of the innate overhead anyway) on the same drive. Now, with the OS running across many more tiles to get the same job done, you very well might see a performance drop, a slight one, but one nevertheless. Now, I have not seen a performance drop, and alone with that I haven't seen any stupid chkdsk checks either at boot because of some annoying error that NTFS can't recover from (whereas I have seen that on the few FAT32 boxes I still have here that haven't been converted yet).

 

HTH

[packman 0]

If you honestly ever suspect having a "hard disk meltdown", wouldn't you rather rely on a complete backup to CD or tape, anyway, to restore everything? I mean, you can do that in either FAT32 or NTFS.

 

I can't see that, just because you formatted to NTFS, rather than FAT32, you're going to prevent a faulty hard disk from completely screwing up. Okay, for lesser problems, where it's not actually the HD that's at fault but, more, some aspect of the OS, I could perhaps believe that NTFS will recover the situation better. But, as I said earlier, I've been running Win2K on FAT32 to date and, on the very infrequent occasions when something HAS gone wrong, Windows has always recovered.

 

Please, please. Someone, convince me that I'm not going to suffer a hikedown in speed if I go to NTFS.With obvious overheads, it certainly looks as though I am.

 

(Incidentally, I notice that, under Win2K's Disk management, you can format in either FAT32 or NTFS, and cluster size anything from 512b to 8KB, but I think that, in practice, Windows prefers to use the default setting and adjusts things itself, according to the size of the partition).

[packman 0]

Clutch,

 

What do you suppose a "small" partition is? 2GB? 10GB? 30GB? Mine are around 15GB each, so which is going to run faster on them, NTFS or FAT32 - and why, precisely? Let's not have waffle.

[clutch 1]

Quote:

Clutch,

What do you suppose a "small" partition is? 2GB? 10GB? 30GB? Mine are around 15GB each, so which is going to run faster on them, NTFS or FAT32 - and why, precisely? Let's not have waffle.

OK, I think MS classifies partitions below 1 or 2GB to be "small" when using NTFS 5. As for me, I consider anything below 10GB to be small but I generally use one partition per drive whenever possible as I hate having the extra drive letters (I map network drives too), and I know that I will be deleting the partition anyway when I reinstall (I keep my stuff on servers at home and work, and if it's of long term worth I burn it to CD) my OS.

So, you want faster performance? Check out the table that's on the link I posted. You will notice that at 15GB you will have 8KB clusters vs. 4KB clusters in NTFS (default formatting). Well, you could format it to 8KB, or 16KB if you like, and then have bigger tiles (and therefore less of them) to work with. However, if you go over 8KB in Win2K, the only defrag software that will work with it is Speeddisk from Norton since they wrote their own API. With some tweaking, I would imagine you could get NTFS to run even faster than FAT32 while retaining the higher security and integrity attributes that it's known for. I have a P3 550 at home running Win2K Server with a WD 120GB drive formatted into a single partition with 8KB clusters and it screams. But then again, this size wouldn't even have been supported with FAT32, and having 4 partitions for that would have sucked (plus zero security).

[Admiral LSD 0]

Quote:

Takes time to backup & restore, but you're right... good practice to perform anyhow! I use NTFS to help avoid having to do that!

Yeah well, I didn't expect the operation (deleting one partition and resizing another over it) to **** up quite the way it did. (I've done it many a time with no ill effects) At least I was able to get out of it, had my disks been formatted as FAT32 I wouldn't have been anywhere near as confident in getting my data back.

[packman 0]

Jwl812,

 

If you're still looking at these postings, what sizes are your partitions?

[packman 0]

Thanks Clutch, for that link. It looks as though there's lots of useful information there. I've printed out all of Chapter 17; it'll make some happy bedtime reading!Hmmm.

 

Be warned, other readers of these postings! To print all or part of Chapter 17 (which is a very full Micro$oft description of all the file systems), you need to rt-click on the first page and select Print. Printing from the Toolbar doesn't work. Do be aware that Chapter 17 comprises 41 pages of A4 (less, I'd guess, with American-sizing).

[Alien 1]

Quote:

However, if you go over 8KB in Win2K, the only defrag software that will work with it is Speeddisk from Norton since they wrote their own API.

I thought it was only 9x/ME that they used their own API for, & that that was the reason why the 2K/XP v. [which, IIRC, uses the MS API] of Speed Disk has less functionality?

[clutch 1]

Quote:

I thought it was only 9x/ME that they used their own API for, & that that was the reason why the 2K/XP v. [which, IIRC, uses the MS API] of Speed Disk has less functionality?

It would appear not, as Speeddisk can defrag (from what I have read) clusters over 4KB in Windows 2000. All the other guys are stuck at 4KB and below, as that is what the MS API was written for at the time. WinXP and .NET don't have these issues though provided you have an updated version of your defrag utility. Ghayes is the man around here on this topic, so if I have some of this mixed a bit, then I hope he corrects it, but so far this description has panned out for me on my systems.

EDIT
After scanning back a bit on this thread, it appears that SpeedDisk uses the MS API only in WinXP, and not in NT or 2K, and hence the ability to get around the 4KB limit. In either case, they can do it on all 3 while the others cannot.
/EDIT