nick@toro.UUCP (Nicholas Jacobs) (05/02/89)
We are running SysV.2 on an NCR Tower 32/650 here and came up with a strange situation the other day. Our machine crashed and when I went to do fsck's on the various file systems, fsck complained about the directory "lost+found" not existing. After a lengthy discussion with an NCR analyst, we discovered that the lost+found directory must exist in each file system. Since this was not documented under fsck (NCR's documentation comes from AT&T), I was wondering if this is the case with all ports of SysV (and/or BSD)? Does this mean that fsck goes into the device file and tries to find the actual directory (I would assume yes...)? Please email any comments and/or suggestions concerning this matter. Thanks, Nicholas Jacobs UUCP: ...!uunet!toro!nick Internet: toro!nick@uunet.uu.net AT&T: (212) 236-3230
chris@mimsy.UUCP (Chris Torek) (05/03/89)
In article <359@toro.UUCP> nick@toro.UUCP (Nicholas Jacobs) writes: >... we discovered that the lost+found directory must exist in each >file system. ... I was wondering if this is the case with all ports of >SysV (and/or BSD)? Does this mean that fsck goes into the device file >and tries to find the actual directory (I would assume yes...)? Most versions of fsck require not only that the lost+found directory exist, but also that it contain sufficient slots to allow any `lost' files to be reattached without having to allocate new blocks. The 4.3BSD fsck (and therefore any based upon it, such as the one in 4.3-tahoe) has the ability to create a new directory and allocate new blocks. I still feel more comfortable having the directory already exist---after all, files being reattached indicate that *some*thing is wrong. It may be something trivial, such as an open but unlinked file in use when the power went out; but it may be that the free block map is completely scrambled, and who knows what further havoc fsck might wreak? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rwhite@nusdhub.UUCP (Robert C. White Jr.) (05/04/89)
in article <359@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) says: > Since this was not documented under fsck (NCR's documentation comes > from AT&T), I was wondering if this is the case with all ports of > SysV (and/or BSD)? Does this mean that fsck goes into the device file > and tries to find the actual directory (I would assume yes...)? As far as i know it is true of every (current?) flavor of SysV and/or BSD Unix Systems. The root directory of the file system being searched is searched for a file named "lost+found" and that inode is used as scratch space for the reconnection of inodes which have no refrences in the directory higherarchy of that file system but have a link count indicating that they should. Since the relinked file is just that "relinked" into lost+found/inode# and no copying or what-not is done, there is no way that fsck *could* put the information onto another file system. It is also true that the directory lost+found must be "slotted" to allow the insertion of the entry without the allocation of any disk blocks because fsck dosn't know at that point if the free chain is valid or not. slotting is the act of creating some number of files in the directory equal-to or greater-than your expected need, and then erasing them (leaving the approprate number of blocks allocated to the now-empty directory). how many slots you allocate is up to you. as part of mkfs our system creates lost+found as a matter of course. I sounds like your doccumentation has been edited, as ours spesifies all this clearly in FSCK(1M) (our 3B2 doccumentation is also direct from AT&T), improperly to whit: "The only restriction is that the directory lost+found must exist in the root of the file system being checked and must have empty slots in which the entries can be made" Rob.
wescott@ncrcae.Columbia.NCR.COM (Mike Wescott) (05/04/89)
In article <1333@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: > in article <359@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) says: > > Since this was not documented under fsck (NCR's documentation comes > > from AT&T), > I[t] sounds like your doccumentation has been edited, ... NCR does indeed edit the man pages, but in this case the information was not deleted, merely overlooked by the reader. We have made mistakes as well as numerous corrections when editting the man pages. This was not the case here though. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM