Re: NTFS recovery

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Wed, 2005-10-19 at 09:25 -0500, Bryan J. Smith wrote:
> *NEVER*, *EVER* CHKDSK a NTFS filesystem *EXCEPT* with the _exact_ NTFS
> installation that created it.  There are links from the filesystem to
> the Security/System Accounts Manager (SAM) which is part of the
> registry, and that is NT installation _specific_.  Even on a dynamic
> disk (LDM disk label, BIOS type 42h), which stores some SID info in
> hidden parts of the disk, it does _not_ have enough to do a CHKDSK.

You might be interested in my Blog from a few months back on the design
of FAT (FAT/NTFS) versus inode (Ext2/3/XFS) filesystem designs:  
  http://thebs413.blogspot.com/2005/08/filesystem-fundamentals-and-practices.html  

It's long, but here's a section on comparing comparing recoverability
from the design of each -- FAT v. inode ...

***  
A FAT filesystem makes it easy to check for free blocks. Inode
filesystems are more arbitrary, and a filesystem consistency check is
always recommended on a regular basis to ensure the number of free
blocks, as well lists of blocks that are available or have been freed,
are consistent. A FAT filesystem also makes it much easier to check for
cross-linked files, whereas all inodes need to be inspected to see if
multiple data blocks are referenced by different inodes (although there
is an interesting bonus to this, as we'll discuss). Inode operations
definitely make checks longer and more involved, although there are
bonuses to this in consistency (which we'll discuss).

A big one to start is actually a surprise to many. Most Windows users
assume that the "root inode" makes an inode filesystem more suseptible
to corruption than a FAT filesystem, because it points to everything
else. In recovery, it's actually the opposite, a major benefit. FAT
filesystems separate the allocation entries (in the fixed FAT) from the
directory references (in special data blocks) which means there are 2
different points where a failure could destroy the same data. Again,
this is because the FAT design comes from MS-DOS 1.0 before directories
were added in MS-DOS 2.1. Although NTFS improves somewhat on this
separation, by allocating directories separate from files, it's still 2
points where either can cause the same, severe damage. Anyone who has
had even a CHKDSK on a NTFS filesystem result in unknown "FILE####.CHK"
files that no one knows about has experienced this issue first hand.

In an inode filesystem, if directory links are severed between the root
inode, or any parent directory inodes below, at least the inodes below
that inode are now their own tree. This is because inodes store both the
directory tree and pointers to data blocks in one structure, the inode
itself. If a filesystem integrity results in the portion of the tree
being "severed," the portion of the tree typically shows up a its own,
self-contained tree under the typicaly "lost+found" directory -- names,
directories, subdirectories, etc... intact. It all depends on the
locality of the corruption or other fixed inconsistency, but if there
was only a few points of actual "corruption," inode filesystems tend to
be much easier to "piece back together" than FAT designs as a result of
the "reference and allocation information as one" inode design.

As an additional benefit, the superblocks also keep a set of "reality
check" values -- allocated data blocks, inodes used, inodes free (if
pre-allocated), free data blocks, etc... These are regularly checked on
boot against other values, and far more interrogated during a full
filesystem integrity check (fsck). In fact, the CHKDSK used for even
NTFS is not nearly as interrogating as an inode filesystem fsck because,
again, the separation of allocation from reference in a FAT design
affords little in the way of allowing a good transposition. FAT is the
FAT, and if things are corrupted in the FAT itself, the day gets really
to be bad. Inode filesystems at least have their own, self-contained
reference lists -- -- both directory, subdirectory, files and pointers
to data blocks.

Lastly, in FAT filesystems, two allocations that points to the same data
block is cross-linked file. In an inode filesystem, this is a "hard
link." Although Microsoft has been trying to come up with hacks to
implement similar in NTFS, they are still not nearly as useful (and are
very dangerous in NTFS). Although hard links sometimes introduce
unforseen issues in rare cases, they are typically very useful for many
things.
***  

-- 
Bryan J. Smith     b.j.smith@ieee.org     http://thebs413.blogspot.com
----------------------------------------------------------------------
The best things in life are NOT free - which is why life is easiest if
you save all the bills until you can share them with the perfect woman


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.