Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!bofh.dot!in-news.erinet.com!imci5!pull-feed.internetmci.com!news.internetMCI.com!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: lost+found directory in 2.1.0R
Date: Sat, 25 May 1996 19:11:42 -0700
Organization: Me
Lines: 55
Message-ID: <31A7BDDE.1EEC223C@lambert.org>
References: <ufu3x4j1hs.fsf@pc142.cs.cuhk.edu.hk>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Arthur S.L. Hsieh wrote:
]
] Recently I've installed FreeBSD 2.1.0R and I notice that all FreeBSD
] partitions created by newfs don't contain lost+found directory
] anymore. I'm curious to know if this is the new behavior of newfs in
] 2.1.0R. If so, any reason to abandon lost+found directory?
This is a change in behaviour in the 4.4BSD UFS. The CSRG folks
said in the comments that the reason for this was that it "was
no longer necessary to precreate it". Here's the *real* reason:
Previous versions of UFS didn't truncate back directory lengths
on delete of the last file in the last directory block, so you
could preallocate a "saftey margin" of directory blocks (which is
what newfs used to do for lost+found). This margin would always
be there because directory blocks, once allocated, stayed allocated.
Since the truncation was integrated, if you created a lost+found,
you'd get one use out of it before it truncated back to nothing,
so the idea of preallocation at all was discarded.
One possible alternate implementation would be to special case
the truncate code for inode 3 (the old lost+found).
The problem here is that as FS's get larger, you'd need to have
the ability to allocate more blocks anyway, so you are faced with
the same problem.
So now fsck creates the lost+found as necessary, and if there
aren't enough blocks to save the entries, then you are in the
same boat as you would have been had the preallocation been too
small: you need to allocate directory blocks.
From an FS Architect's perspective, I'm not terribly happy with
the soloution the CSRG guys arrives at here, but short of going
to soft updates (which, if correctly implemented, never require
fsck at all), there's no good workaround.
Note that the BSD 4.4Lite and Lite2 code's fsck had a bug in
it when it had to create lost+found: it left the root directory
inode reference count set incorrectly. I posted a patch for
fsck to the -current list -- I think it has been integrated into
-current if you want it. Without the patch, you have to fsck
twice: once to create the lost+found, and once to fix the root
inode reference count.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.