Subject: Re: Defragmenting a NetBSD drive
To: None <email@example.com>
From: Guenther Grau <Guenther.Grau@bosch.com>
Date: 09/16/1999 17:39:46
Brian Buhrow wrote:
> If a program is scanning a directory and collecting the entries in the
> directory, and another process is modifying the entries by shufling them
> around and re-ordering them, either by moving them toward the beginning of
> the directory or deleting them entirely, the process scanning the directory
> could either miss entries which actually exist, get double entries as it
> scans over a name twice, or otherwise read off the end of the directory
> because its sized changed in the middle of its scan. To avoid this
> problem, you'd need to implement some sort of locking or transaction
> protocol to guarantee atomicity for a directory scan. That problem,
> combined with the relatively modest improvement in disk storage efficiency
> seems not to be a good fit for a substantial amount of work. Few
> directories take up many extra blocks unnecessarily and disk blocks are
> getting cheaper every day.
Hmm, I think we are talking about two different things here.
The first thing is my question:
> } > | Hmm, why does the compaction happen creation time, not when an
> } > | entry is deleted?
[ replaced directory by entry, because that's what I meant :-) ]
I think the reason for this is efficiency. As Robert pointed out
extremly well, creat() has the knowledge and the work already there
to do this, while unlink() would need to do additional work.
The second question is, why is there no "real" compaction done,
where "real" is shuffling entries around in the directory to
fill the holes and free any additional blocks at the end. The
answer to this is what you wrote above (and Robert in his response
to my mail). I agree with both of you, although, from the purist
point of view, it might be a feature worth implementing. The
unlink() just needed to lock the directory and all other tools
trying to access this directory would fail to open it. But then
again, if it were a real problem, people would have solved it
by now, so it obviously is nothing to really worry about :-)
Thanx again to both of you for this enlightment!