Date: Tue, 7 May 1996 00:43:14 +0200 (SAT) From: Robert Nordier <rnordier@iafrica.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org Subject: Re: dosfsck anyone? Message-ID: <199605062243.AAA00740@eac.iafrica.com> In-Reply-To: <199605060850.SAA14400@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 6, 96 06:20:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 May 1996, Michael Smith wrote:
>
> Robert Nordier stands accused of saying:
. . . . .
> > An example of this danger is the case of cross-linked directories.
> >
> > (If the directories /junk and /keep are cross-linked, they immediately
> > or eventually merge into a common chain of directory entries, because
> > they share all but zero or more initial allocation units).
>
> Hmm. I'd be inclined to suggest that all the directory entries out of
> the merged section should be moved into the equivalent of a 'lost+found'
> directory, perhaps in a subdirectory containing a .REPORT file indicating
> where they came from and when...
>
> Putting them in one or another of the original directories hides the
> problem. I don't think that the aim of a filesystem repair tool under
> such circumstances should be to try to hide the problem, but rather to
> facilitate the manual repair of the filesystem.
Agreed 100%.
>
> > A more flexible approach might be as follows:
> >
> > Directory '/junk' cross-linked on cluster 4. Truncate [yn]?
> > [other stuff may intervene]
> > Directory '/keep' cross-linked on cluster 4. Truncate [yn]?
>
> Directories '/junk' and '/keep' crosslinked on cluster 4.
> Move files to '/losfound.fsk/dosfsck.001' ** ANSWERING NO WILL DISCARD FILES **
> [yn]?
>
> > A related issue is whether to discard, or continue to queue, Change X
> > (approved by the user) when - with hindsight - Change Y renders Change X
> > unnecessary, or even misguided.
>
> I think that it would be desirable, where possible, to present the symptoms
> of a single problem together. I'm aware this leads to messages like :
>
> Too many directories (>256) crosslinked. Suggest discarding filesystem!
That's a great line. There's got to be a place for it, even if the
error condition has to be specially arranged. 8)
One consideration is that problem-by-problem info may be difficult
to present intelligibly, if the filesystem structure has become really
confused.
Consider the case of five directories (/a /a/b /a/b/c /d /e) which
have become cross-linked:
+-<----------------------------+
+-----2 | +-----3 +-----4 |
<a> ---> | | -+-> | | -+-> | <b> | |
+-----+ +-----+ | +--+--+ |
<d> ------------------------->-+ | +--+--5
+--+--> | <c> |
| +-----+
<e> ----------------------------------->-+
The first cross-link is to cluster 3. One directory involved is '/a',
and the other is 'c', but what canonical 'c' is, is anyone's guess:
'/a' and ('/a/b/c' or '/d/b/c' or '/e/c')
Once we replace the cluster 3 cross-links with a link from
'/losfound.fsk/dosfsck.001', we face a choice of how to represent the
next set of cross-links (cluster 4). This could be as (updated
structure):
'/losfound.fsk/dosfsck.001' and '/d'
or (original structure):
'/a' and '/d' and ('/a/b/c' or '/d/b/c' or '/e/c')
OTOH, if the cross-links are dealt with in tree traversal order, as
we come to them, the natural effect of each truncation is to reduce
the structural ambiguities:
/a cross-linked on 3. Truncate [yn]? y
/d cross-linked on 4. Truncate [yn]? y
/e cross-linked on 5.
/e/c cross-linked on 3.
/e/c cross-linked on 4.
/e/c/b cross-linked on 5. Truncate [yn] y
Another thought: scattering (say) 'cross-linked on 3' info all over
the place may actually be beneficial _because_ it makes things
harder for the user. Problems like this really need an info-gathering
pass before the suggested changes are approved. If users have to
postpone decisions because of insufficient specific info, at least
they are being forced to look at the overall picture first (while
taking notes 8).
>
> > One compromise might be not to allow truncation of both directories,
> > thus avoiding large-scale structural changes. In this case, 'dosfsck'
> > provides the means for eliminating detectable structural anomalies, and
> > leaves it up to the user to cope with possible, non-detectable corruption.
> > So the common clusters must be allocated to either /junk or /keep, and can
> > be (re)moved by hand if found to be incorrect.
>
> Is it difficult (and thus messy) to take the common clusters and allocate
> them to a third directory (as in the example above)? If so, there's a
> precedent for taking the easier way out 8)
I particularly like the concept of moving questionable directory
clusters to either the root or to some form of '/lost+found'. The
main stumbling block, though, is that clusters (other than the
first directory cluster) will be missing '.' and '..' entries.
And if the relevant directory slots are occupied, it's hard to know
how to proceed ('fsck' itself just expects the user to rectify the
situation by hand).
When VFAT support is added, there is the additional problem that
a single long filename may be spread across about 14 directory
entries. If a cluster boundary intervenes between the 15 entries
relating to a given file, the long filename will be lost.
So there is the chance of introducing definite structural anomalies
in the act of rectifying only possible/probable directory corruption.
>
> > A further possible approach is simply 'So what? Provide an arbitrary fix
> > for the problem. In the real world, most users will either restore from
> > backup, or fix the problem themselves, either by hand or with some other
> > utility.'
>
> Good point. Hence, perhaps, the idea that data in contention should be
> kept but removed from any potentially incorrect location, keeping only
> those parts of the tree that appear to belong where they are.
> (I'm aware that this is somewhat of a subjective decision 8)
If there was a good solution to the '.' and '..' problem, this
would be distinctly attractive. One way out, I suppose, would be
to use unallocated clusters, if necessary, and actually transfer
the questionable directory entries individually (and somewhat
intelligently, for VFAT), making the process a partial directory
rewrite rather than a relink.
I'm a bit wary of using apparently unallocated clusters, though.
If there are many cross-linked directories, this may well be because
of damage to the FAT. So what may seem to be available clusters
may actually be stuff the user really needs, and would be prepared
to recover by hand.
Anyway, I guess I've got to the stage of finding too many reasons
why any given approach is problematic. 8( Maybe the lesson from
'fsck' itself is not to try too hard, or check too much. There
are a number of things 'fsck' just doesn't check (duplicate names
within a directory, for instance). I'll give the stuff a break
for a bit, and then consider the suggestions again....
--
Robert Nordier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605062243.AAA00740>