NEWB & NTFS - Explain it yous guys :)

[rosco6912]

Ok, so people are always saying that NTFS is better than FAT32 b/c it offers more security... Well, can someone explain how/why? Is it the encryption options? How do they work? Just looking for a bit more than "FAT32 < NTFS" Thanks in advance

 

[LittleAl]

I can't explain it any better than this:
Choosing Between FAT and NTFS

and this:
NTFS compared to FAT and FAT32

 

[glugglug]

Those articles are very biased because M$ would like everyone to stop using the "legacy" filesystem and OSes ASAP.

Yes, NTFS offers MANY advantages such as setting separate access permissions for each file/directory, compression, sparse files, encryption, & a few other things.

However, with the exception of compression possibly, > 99.5% of home users will NEVER take advantage of any of these features.

FAT32 is faster than NTFS no matter what the partition size. Period. The difference is less on larger drives, but contrary to popular myth NTFS is never faster no matter how large the drive. On a modern system the lower CPU overhead of FAT may not be noticable unless you're dealing with thousands of tiny files (its about a 50% difference, but 50% of the less than 5% of your CPU time being used for disk access isn't that noticable). If you're running an application that seeks around a lot its quite significant however.

Unfortunately as part of the phasing out of this legacy filesystem Win2K/XP impose extra unnecessary limitations on it to make it less attractive, most notably they only let you format partitions up to 32GB as FAT32. This is an OS limitation, NOT a filesystem limitation.

 

[CTho9305]

Originally posted by: rosco6912
Ok, so people are always saying that NTFS is better than FAT32 b/c it offers more security... Well, can someone explain how/why? Is it the encryption options? How do they work? Just looking for a bit more than "FAT32 < NTFS" Thanks in advance

I have managed to lose data on fat32 partitions after crashes. I haven't with NTFS. (Anecdotal evidence)

 

[bsobel]

FAT32 is faster than NTFS no matter what the partition size. Period. The difference is less on larger drives, but contrary to popular myth NTFS is never faster no matter how large the drive. On a modern system the lower CPU overhead of FAT may not be noticable unless you're dealing with thousands of tiny files (its about a 50% difference, but 50% of the less than 5% of your CPU time being used for disk access isn't that noticable). If you're running an application that seeks around a lot its quite significant however.

Wrong. NTFS is often quite faster, especially when dealing with directories with many files in it.

Unfortunately as part of the phasing out of this legacy filesystem Win2K/XP impose extra unnecessary limitations on it to make it less attractive, most notably they only let you format partitions up to 32GB as FAT32

It is a file system limitation, the cluster size gets to large it's stupid to use FAT32.

Bill

 

[glugglug]

Wrong. NTFS is often quite faster, especially when dealing with directories with many files in it.

Ever actually test this? I have. Specifically trying to optimize a process which creates millions of files (average < 10k) from an incoming data feed and organizes em into thousands of directories FAT32 handled 225-235 files/s while NTFS could only do 160-170 on the same 120GB WD SE. The NTFS partition even had the advantage of being earlier on the disk for more data/track (and no it wasn't the system disk at the time).

Testing different low-level operations the only thing I've found NTFS to do faster is create a new EMPTY directory. This is most likely because NTFS doesn't even allocate any space for the directory until you place a file in it -- empty directories in NTFS are actually listed as consuming zero clusters (although if you create enough of em the directory containing them starts to grow) while in FAT32 an empty directory consumes 1 cluster.

It is a file system limitation, the cluster size gets to large it's stupid to use FAT32

Only if formatted with the M$ tools for it (like win2k/xp installer), which stupidly switch to 8K clusters for volumes above 8GB, and 16K clusters for volumes 16-32GB. With other tools such as Partition magic, you can have 4k clusters on a FAT32 partition up to 1 TB, or theoretically even 512 BYTE clusters up to 128GB (although the FAT table itself occupies an enormous 1GB in that case).

 

[bsobel]

I have. Specifically trying to optimize a process which creates millions of files (average < 10k) from an incoming data feed and organizes em into thousands of directories FAT32 handled 225-235 files/s while NTFS could only do 160-170 on the same 120GB WD SE. The NTFS partition even had the advantage of being earlier on the disk for more data/track (and no it wasn't the system disk at the time).

Then your test was flawed, I've tested both file systems with thousands of files per directory. If you saw problems with 160 files on NTFS you had something else wrong in your test configuration.

Testing different low-level operations the only thing I've found NTFS to do faster is create a new EMPTY directory. This is most likely because NTFS doesn't even allocate any space for the directory until you place a file in it -- empty directories in NTFS are actually listed as consuming zero clusters (although if you create enough of em the directory containing them starts to grow) while in FAT32 an empty directory consumes 1 cluster.

Directories (like small files) consume an MFT record.

Only if formatted with the M$ tools for it (like win2k/xp installer), which stupidly switch to 8K clusters for volumes above 8GB, and 16K clusters for volumes 16-32GB. With other tools such as Partition magic, you can have 4k clusters on a FAT32 partition up to 1 TB, or theoretically even 512 BYTE clusters up to 128GB (although the FAT table itself occupies an enormous 1GB in that 512 byte case).

4k clusters are useless when your fat is too big to fit into memory when the os tries to boot.

Bill

 

[amdskip]

http://anandtech.com/guides/viewfaq.html?i=63