On Sun, 02 Jan 2005 20:31:27 GMT, Robert Hancock
>cquirke (MVP Win9x) wrote:
>> In practice, MS is not concerned with your data at all; only the
>> sanity of the file system.
>> The trouble is, these matters will only come to a head when things go
>> wrong. Even then, the user has to believe what the tech says, and
>> many techs are insufficiently skilled or concerned about data
>> recovery. So bogus claims like "NTFS saves you from data loss because
>> of journalling and transaction rollback" are rarely challenged.
>I think that the main claimed advantage of NTFS journaling is that it
>avoids the need for a full chkdsk after an unclean shutdown. This is not
>such a big deal for a home system, but if you have a server containing
>hundreds of user profiles and many thousands of files, the time it takes
> to run a full file system check is very significant (many hours in
>some cases, apparently), during which time the server is not available.
I attain that advantage in a different way; by keeping C: small and
uncluttered. Most write traffic (temp, pagefile, TIF) is on C:, so C:
usually has to be checked after a bad exit, plus the traffic load
means C: is most likely to get corrupted and lose data.
So with an 8G C: and data held on a 2G D:, the "difficult" parts of
disk maintenance (AutoChk after bad exits, defrag) are fast. It's
less often that the bulk of the HD (E
would have to be checked.
>There are some advantages as far as data integrity however - in FAT32,
>etc. there are probably some cases where the file system state after a
>crash can't be reconciled properly and some files end up orphaned or
>lost, NTFS would prevent this from happening.
These are the details I'm trying to pin down, but most folks just trot
out "NTFS is more secure" (true, but not relevant at the level of
abstraction I'm looking at) or point to journalling as if that could
prevent wild writes or HD failure from corrupting data.
NTFS is not "like FATxx but better"; it's a completely different file
system. For example; there's no FAT, and directories are indexed
rather than searched from beginning to end. What do these differences
mean, when it comes to the risk of corruption and data loss?
Well, avoiding linear directory lookup could reduce the critical
window for directory updates, if it means an entire cluster chain
doesn't have to be written back to disk whenever a directory entry
changes. On the other hand, it's far easier to manually repair a
"flat" file than to fix a binary index.
As to "no FAT"; well, the information about which cluster comes next
has to be stored somewhere. As I understand it, free clusters are
tracked in a bitmap, while data cluster chains are managed as "runs".
Both of these shrink the size of the metadata required, compared to a
FAT that stores an entire address for every data cluster. A bit to
mark "used" may be required for every cluster, but that's a lot (er,
1/32) smaller than 32 bits per cluster address.
By the same token, it should take less space to hold only the starting
cluster address for each contiguous fragment of a file's total data
clusters. Only those clusters that start a piece of teh chain have to
be tracked; the rest are implicitly assumed to follow for the length
of that particular cluster run.
What is not clear, is to what extend these crucial structures are
duplicated for safety - given that there's no other way to deduce what
they should be. FATxx has two copies of FAT; does NTFS maintain two
copies of the free space bitmap and cluster run information?
Finally, there's the matter of how to fix things when (not if) they go
wrong - and this is where NTFS truly sucks. It's not the fault of
NTFS as a file system design; it's the lack of decent tools.
When FATxx gets bent, I can use Scandisk interactively to scout the
problem. Scandisk stops when it finds an anomaly and asks me if it
can "fix"; if it looks safe, I let it, else I abort and move on to
Diskedit (a 3rd-party tool from Norton Utilities).
Diskedit also checks the file system for errors, but doesn't fix;
instead, it lists the errors so I can "jump" to them. Diskedit shows
the raw contents of the HD in ways appropriate to the content, e.g.
MBR as MBR, FAT as FAT, dir as dir etc. but I can choose any view I
like, which is helpful for "lost" items.
With a working knowledge of FAT structure - it's simple, and it's
documented - I can manually repair or rebuild file system structures
to taste. In this way, small file system barfs can be fixed cleanly,
with less data loss than if it were left up to Scandisk.
In the case of NTFS, I don't even have an interactive Scandisk. In
fact, in some ways it's worse than the old disk compression stuff that
we avoided for fear of data loss. The only tool I have is ChkDsk,
which either fixes nothing and may throw spurious errors, or ChkDsk /F
that automatically and irreversably "fixes" things. It's a disaster!
>--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
>--------------- ----- ---- --- -- - - -
FAQ
Search
Profile
Private Messages
Log in
