C
cquirke (MVP Win9x)
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
Well, do the maths. If files are 150k, and cluster space is 32k
rather than 4k, then the biggest wasteage would be 32k-4k = 28k per
file. Assume actual wastage is half that, i.e. 14k, per file. That
boils down to under 10%; significant, but not carnage.
OTOH, if it's more like 2M per file, this drops to an under 0.7% shrug
As suggested by your figures about start menu shortcuts.
Those are 500-*byte* files, not 150 000 - 2 048 000 bytes
What will really waste space would be IE web cache...
Other considerations of the original poster were "resilience, recovery, ease
of repair".
Yep - and once again, NTFS isn't quite what it seems.
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.
Haven't seen that, unless you are using disk compression. Read up on
the shuffling NTFS does when it fills up... I can see the same sort of
widening of critical windows there, as it re-balances between MFT and
data space. Problems may also arise when software that assumes
limitless memry (as bounded only by free swap space) hits the wall.
In such situations, it becomes tricky to save the OS, and depending on
the seriousness of the crash, data loss possibilities are considerable.
I've done a lot of data recovery on FATxx, and that's the point; it is
possible to recover lost data in such cases.
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.
Read: The damaged data is stimply and irreversably destroyed.
This is what I mean; NTFS "doesn't need" Scandisk simply because it
behaves as if Scandisk was running all the time, with the most
ruthless trade-off between your data and file system integrity.
That is NOT what I consider "data safety".
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.
Exactly. Some of us would prefer to recover truncated or partial
data, but you don't have that option with NTFS.
Consider a power outage occuring during a defrag process
of a FAT drive. The possibilities of errors is high on a FAT partition
Sure; that alerts you to what files are damaged - but at least you
have a chance at recovery of partials. With NTFS, it's simply gone
without a trace, and no way of getting it back.
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,
Specifically, file data and attribute metadata are held in the same
way, as streams. Streams are effectively cluster chains containing
content that hang off a dir-level entry; a structure that's familiar
from working in PICK.
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.
By metadata, I was referring to that within the directory level, not
within the streams. But you do raise an interesting point - that
bloated metadata are not "free" if it effectively means two or more
cluster chains to look at in addition to the dir level.
Earlier on, someone made the claim that NTFS keeps redundant copies of
the dir structure. What I read suggests it's only the first few
entries that are held in that way - in effect, a similar result as
predictable locations for these core structures as applies in FATxx
(where this knowledge is the "redundant copy").
Our senses are our UI to reality------------ ----- ---- --- -- - - - -