Date: Fri, 22 Mar 1996 11:58:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrm@Sceard.COM (M.R.Murphy) Cc: freebsd-current@freefall.freebsd.org, joerg_wunsch@uriah.heep.sax.de, terry@lambert.org Subject: Re: lost+found ??? Message-ID: <199603221858.LAA03059@phaeton.artisoft.com> In-Reply-To: <9603220654.AA23195@Sceard.COM> from "M.R.Murphy" at Mar 22, 96 06:54:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I disagree :-). I'd prefer the SVR2 approach of a separate simple script
> to create, populate, and then depopulate lost+found, remembering the
> concept that a tool should do one thing, of course. The reason for
> populate/depopulate is to insure that an expanddir isn't necessary in
> the fsck processing. Terry?
If you populate lost+found to preexpand it, then depopulate it, the 4.4
UFS directory compaction code will once again remove the space. In 4.4
unused directory blocks are reclaimed through truncation.
This only worked in previous releases because directories were only
grown, never shrunk. To recover unused space, you'd need to backup
and restore, or make a new directory and "mv" everything there, and
delete the old one.
I'm pretty sure that what happened is the directory truncation code
caused them to worry about this, and they copped out on special
casing inode 3. Once they were in for a penny, they might as well
be in for a pound, and they copped out on the creation ("no, that's
a feature"). I simply don't buy the "deterministically recoverable"
argument when block allocation is involved.
To do something about this would require modifying the FS code so that
inode 3 is always used (again), and so that the dir code specifically
*didn't* truncate inode 3 below 8k (or whatever the magic number is).
On the subject of the 8k, Bruce is wrong about the requirements: the
most you have to deal with is the number of files allowed to be a
problem with properly ordered updates: basically, one directory
worth of names... and in that case, you'll get blocks back from
the directory that died. It's still possible to overflow the 16
additional (reserved) blocks, but it's unlikely.
Of course if you mount async, all bets are off. 8-(.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603221858.LAA03059>