Re: Fat32 vs NTFS ?

From: Ad (graphi47uk_at_y.a.h.o.o.co.uk)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 00:48:21 +0000

DevilsPGD wrote:

>
> Sure, if it's user data located in the cluster(s) that become unreadable
> you're pretty much out of luck no matter what file system you use

Correct, so if you are using NTFS or fat32, you still lose the data.

> (unless there is redundant data -- I'm not aware of any file systems
> which attempt to store redundant data on the same physical drive,
> although you could probably do it with NTFSv5 if you wanted to -- I'm
> pretty sure you could create mirrored partitions on the same physical
> drive, but I've never tried it -- The performance would be killer for
> writes though)

Oh yes, I expect it would be, that is where raid comes in.

>
> However, if a FAT16 drive's MFT happens to go, you effectively lose the
> entire drive (unless you're willing to review, cluster by cluster, the
> entire data portion of the drive to identify files. You won't know when
> one file ends and another begins, and you may not even know where the
> rest of a file is if you find part (since the drive might be fragmented)
>
> With NTFS, the data is distributed around the drive, meaning that if you
> lose a cluster (or even a bunch of clusters together) which contain
> metadata, you won't lose as much user data.
>
Maybe so, but even if you lose some data, then as I said above, that
file is useless.
The only file you may be able to recover is text files.

>
>
> Why? Because the fragmentation map doesn't look as pretty, or because
> you notice a performance hit?

I notice a performance hit.

>
> Don't get me wrong -- There are cases where an NTFS formatted partition
> will fragment more then FAT, but this is fairly rare in typical
> applications.
>
> When a file is created in an NTFS formatted drive, if the application
> sets the size of the file up front, if there is any contiguous free
> space on the disk large enough to hold the file, it will be placed
> there, and the file will not fragment.

I think you better have a better look then, becuase that do not happen,
I got a fair bit of space on my drives and yet with NTFS, they still get
fragmented like hell, even after a week. I just got fed up of Deraging
all the time.

>
> Typical FAT implementations just start writing the file (the start
> position varies somewhat, but typically at or near the place where the
> last write occurred) without regard to the fact that if the file had
> been placed elsewhere on the drive, it wouldn't have fragmented.
>
> The easiest way to get a fragmented file in an NTFS partition is to
> create a small file and append to it in a drive where the free space is
> highly fragmented.
>
> Also, NTFS will tend to leave free space somewhat fragmented by design.
> This is not a bad thing, although it doesn't create as pretty a map in
> defragmentation software. The reason is that when a new file is
> created, NTFS will tend to place that file physically near other files
> in the same directory. The downside is that if a drive is near
> capacity, you'll see a huge amount of fragmentation.

So you say, but when my hard drives is clunking away after only a week,
then I tend to worry.

>>I am not sure how to use it really, since I have never needed it.
>>I can not see how any compression can be a performance boost.
>
>
> I have some VHD files that are around 4GB in size, but compress to 25%
> of their original size.
>
> When I copy one of those VHD files the drive only reads 1GB and writes
> 1GB. If compression was disabled, the drive would have had to read 4GB,
> then write 4GB.
>
> In other words, with compression enabled there is only 2GB of disk I/O,
> whereas with compression disabled there would have been 8GB of disk I/O.

But surley this would be slower, due to the compression
>
> The other factor is that while CPU speeds have drastically increased
> over the past few years, hard drive speeds haven't kept pace. Even if
> the goal was simply to read the file (and do something with it other
> then just write it, which doesn't require a decompression/recompression)
> you can still see a performance boost in some cases.

But not for the normal person in the street who just wants to use their
computer, for writing the odd letter, surfing the net and playing a few
games.

> My laptop's drive spins at 4200rpm, which results in a read speed of
> approximately 25MB/s. However, since it has a 3.0GHz CPU which is
> largely idle most of the time. It only takes a few percentage of CPU to
> decompress a NTFS compressed file which is being read at 25MB/s, so the
> resulting read speed for a file which is compressed 50% is roughly
> 50MB/s.

That is a slow hard drive? most of them are around 7200 now, or are
laptop hard drives slower?

> Imagine this taken to an extreme -- An external USB drive connected to a
> PC with only USB 1.1 ports. You'd do a lot better with better
> compression then NTFS offers (NTFS compression is optimized for low CPU
> use rather then the best possible compression)
>

But how many people would really need to use it and to be honest, how
many people would know how to use it?

>
> Sure, but that's not a filesystem issue -- It happens equally under any
> LFN-capable file system.

I did not say it was a file system issue, I was just trying to point
out, the long filenames are not always a good thing.

>
> The difference is that as soon as you exceed 8.3 characters, FAT wastes
> directory records breaking the filename down into 8.3 chunks.
> Admittedly in a multiple-GB drive, wasting a few MB in unused directory
> records isn't a big deal, but it's still a stupid design (although a
> necessary one, since LFNs were bolted in after the fact -- I can't think
> of a better way to do it, other then to store the LFN information as
> metadata in a file located elsewhere on the drive -- This would result
> in a huge performance hit since that file would be physically separate
> from the directory structure, require the drive heads to move)

That is the way things go, things get bolted on all the time, I expect
NTFS have things bolted on that it was never meant to use.

>>Why? I am happy with FAT32, I should never have changed to NTFS in the
>>first place, I was warned and ignored it.
>
>
> My sympathies with regards to WinME.
>

That is a pain, I must admit, I have now gone back to XP, but still with
fat32.

Loading