Re: FAT32 or NTFS?
From: DILIP (dilipr_at_#*&!%l.com)
Date: 05/10/04
- Next message: john tee: "Microsoft voice recognition"
- Previous message: CWatters: "Re: OEM windowXP a one-time installation ?"
- In reply to: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Next in thread: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Reply: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 10 May 2004 14:03:49 +0530
"cquirke (MVP Win9x)" <cquirkenews@nospam.mvps.org> wrote in message
news:7ams901lkvflqa83usmqj0vo3hhepn0893@4ax.com...
> On Sun, 9 May 2004 13:44:52 +0530, "DILIP" <dilipr@#*&!%l.com> wrote:
>
> >FAT32 does claim to support partitions up to 2TB, but it does so at the
cost
> >of a hugely bloated FAT and large cluster sizes, which is wasteful and
> >undesirable.
>
> Don't get mesmerized by cluster size - it's not always relevant, and
> in the circumstances discussed here, largely irrelevant.
The jpegs will affect the equation here. The average size of a picture,
depending on its source may be anywhere between 150KB for web photos to
2-3MB for those downloaded from a digital camera. If we consider the former,
it would not be incorrect to assume that the wastage in such a scenario,
with many small files, would be considerable - As suggested by your figures
about start menu shortcuts.
Other considerations of the original poster were "resilience, recovery, ease
of repair".
resilience --- As far as FAT partitions go, don't forget to wave goodbye to
your all data and the OS, when the disk becomes over full. This has happened
to me once already. In such situations, it becomes tricky to save the OS,
and depending on the seriousness of the crash, data loss possibilities are
considerable. Of course this is just one example.
recovery and ease of repair --- NTFS file systems don't need a scandisk add
on per se, simply because they don't need one. Data verification
technologies imbedded in the file system ensure that data is only written on
to the disk, when it is verifyible. If it cannot be read back, the
transation is simply rolled back. Which brings me to this - In an NTFS file
system, a transaction is either performed completely or not performed at
all. It's 1 or 0. Consider a power outage occuring during a defrag process
of a FAT drive. The possibilities of errors is high on a FAT partition
afterwards. However, the NTFS file system can easily recover from such a
situation due to the transaction log meta file that it reads at the next
boot. Meta file start with $ such as $Logfile, $Boot, etc.
This is why I feel that NTFS is the way to go for large partitions on NT
based systems, such as this scenario. Pl note that, the user does not
mention any dual boot scenario here.
One more thing, you mention that "the tiny file data would be held entirely
within the directory entry metadata." Wouldn't this be stored in the MFT?
metafiles as such, (as I have read anyway) refer to the files created when
an NTFS partition is first created (sixteen), and contain volume & cluster
information; strictly speaking unavailable to the OS. Under NTFS, there is
no specific difference between a file and a collection of attributes,
including data contained in the file itself. When the space required for all
the attributes is smaller than the size of the MFT record itself, then the
data attribute is stored within the MFT record itself. Please clarify what
distinction you consider between MFT and metadata.
Cheers
I usually don't quote, but as Will Durant once said, "Education is a
progressive discovery of our ignorance."
>
> >"Plato" <|@|.|> wrote in message
> >> Bruce Chambers wrote:
>
> >> > capabilities, no fault tolerance, and a lot of wasted hard drive
space
> >> > on volumes larger than 8 Gb in size. But your computing needs may
>
> >> Not an issue with large files as mp3s and videos and such.
>
> Here's some real figures off a client's PC I am working on...
>
> Volume: D: (FAT32, 120G, 32k clusters)
> Content: Video files
> 140 files, 10 folders, 13.4G
> Average file size; 96M
> 14 391 101 876 bytes of data
> 14 393 475 072 bytes of space occupied
> 0.02% capacity wasted in slack space
>
> Volume: D: (FAT32, 120G, 32k clusters)
> Content: MP3 music files
> 8 976 files, 703 folders, 42.3G
> Average file size; 4.7M
> 45 448 637 616 bytes of data
> 45 598 375 936 bytes of space occupied
> 0.33% capacity wasted in slack space
>
> Volume: C: (FAT32, 7.9G, 4k clusters)
> Content: The Start Menu subtree of shortcuts
> 479 files, 63 folders, 273k
> Average file size; 0.5k
> 280 362 bytes of data
> 1 945 600 bytes of space occupied
> 85% capacity wasted in slack space
>
> ...so whereas a "one big C:" layout would undoubtedly be wasteful of
> space, this is a trivial issue when storing only large files.
>
> NTFS would be very space and speed efficient for that start menu, not
> because of the smaller clusters (in fat, they'd be the same size as
> FAT32 on this sub-8G volume anyway) but because the tiny file data
> would be held entirely within the directory entry metadata.
>
> That means while FAT32 has to pull up 1 + 63 + 479 data clusters to
> handle the menu (2M for only 275k or data), NTFS would have it all in
> those 1 + 63 directories.
>
> Not that those directories would themselves be as small as they would
> be in FAT32 - after all they contain the file data here :-)
>
>
>
> >---------- ----- ---- --- -- - - - -
> Certainty may be your biggest weakness
> >---------- ----- ---- --- -- - - - -
- Next message: john tee: "Microsoft voice recognition"
- Previous message: CWatters: "Re: OEM windowXP a one-time installation ?"
- In reply to: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Next in thread: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Reply: cquirke (MVP Win9x): "Re: FAT32 or NTFS?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
