From owner-freebsd-hackers Mon May 6 15:53:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA15351 for hackers-outgoing; Mon, 6 May 1996 15:53:37 -0700 (PDT) Received: from eac.iafrica.com (h196-7-192-132.iafrica.com [196.7.192.132]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA15340 for ; Mon, 6 May 1996 15:53:28 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id AAA00740; Tue, 7 May 1996 00:43:15 +0200 From: Robert Nordier Message-Id: <199605062243.AAA00740@eac.iafrica.com> Subject: Re: dosfsck anyone? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 7 May 1996 00:43:14 +0200 (SAT) Cc: hackers@freebsd.org In-Reply-To: <199605060850.SAA14400@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 6, 96 06:20:01 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 | ---> | | -+-> | | -+-> | | | +-----+ +-----+ | +--+--+ | ------------------------->-+ | +--+--5 +--+--> | | | +-----+ ----------------------------------->-+ 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