Subject: Re: Defragmenting a NetBSD drive
To: Robert Elz <kre@munnari.OZ.AU>
From: Guenther Grau <Guenther.Grau@bosch.com>
Date: 09/16/1999 11:58:18
Robert Elz wrote:
> | Hmm, why does the compaction happen creation time, not when a
> | directory is deleted?
> Obviously it does happen when a directory is deleted - the whole thing
> is freed then .. but I assume you mean when an entry is removed from
> a directory.
Uh, right :-) I was actually thinking that the entry removed from the
directory was a directory itself :-) But, you parsed my babbling
> So, directory trimming is done by creat(), rather than by unlink().
> | Why are directory entries not compressed when a directory gets
> | deleted? The fs could move the entries around, couldn't it?
> It could, but it isn't quite as easy as it seems - the kernel part
> isn't too difficult, but the effects on applications which are scanning
> the directory at the time need careful thought - and that tends to
> end up suggesting that it is best to just leave the directories alone.
Hmm, I don't quite understand that. If an application is scanning a
directory while an entry (yes, I this time I got it right :-) is
deleted from/added to it, the directory structure is changed behind
the application. Why does it make a difference to application if the
creat() code does the compaction instead of the unlink() code?
> If some human decides to shuffle things around, that's OK, they can
> then understand why some files might not have been properly found when
> something else was scanning the directory - but having the kernel just
> arbitrarily doing that because it feels like it might be useful probably
> isn't such a wonderful idea.
Well not but at unlink() time. :-) Right now it happens
"arbitrarily" as creat() time ;-)
> | I guess this is not done for performance reasons, right?
> No. Its the side effects.
I am not convinced yet :-)
Thank you very much for your excellent and detailed explanation!!!