From owner-freebsd-hackers Thu Jan 19 09:23:39 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA26409 for hackers-outgoing; Thu, 19 Jan 1995 09:23:39 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA26403 for ; Thu, 19 Jan 1995 09:23:38 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07426; Thu, 19 Jan 95 10:17:31 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9501191717.AA07426@cs.weber.edu> Subject: Re: No lost+found? To: roberto@blaise.ibp.fr (Ollivier ROBERT) Date: Thu, 19 Jan 95 10:17:30 MST Cc: terry@uivlsi.csl.uiuc.edu, hackers@FreeBSD.org In-Reply-To: <9501190913.AA17551@blaise.ibp.fr> from "Ollivier ROBERT" at Jan 19, 95 10:13:13 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > When you'll have a crash, fsck will create the lost+found directory > itself and expand it as necessary. One of the points of the lost+found directory being there in the first place is that it must have a particular inode number (root is inode 2, lost+found is inode 3). Another point of having it precreated is that it comes preinitialized to 8k (16k in the file system I recently worked on for USL, since the directory entry blocks were twice the size), is that there *will* be room to put the entries to recover it. In other words, you don't *want* fsck to have to allocate a potentially non-existant free inode, make a directory entry in / (potentitally allocating a non-existant free free block to add the name to the end of the / directory contents), and allocate more potentially non-existant free blocks to extend the lost+found directory as files are recovered. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.