Re: unlinkd ??

In article <199704031152.DAA01673@salsa.gv.tsc.tdk.com> you write:

>It just occured to me that a better strategy might be to just truncate
>the file to zero length. That would eliminate the need to update
>the directory when removing the object, then updating the directory
>again when storing a new object (both of which probably involve
>synchronous writes if you're using FFS). Also when a new directory
>entry is created, the entire directory must be scanned to see if
>that name already exists, whereas reusing an existing directory
>entry will on average only scan half the directory.

1.1.9 already includes something like this. Cache files which become
obsolete have their name (/cache/XX/YY/ABCDEFGH) stored on a stack
(default 128 entries). When a new cache file is required the stack is
inspected and the top element is returned. A write to that file name will
overwrite the old, obsolete, object.

When the stack is full, the name of the file is passed to unlinkd which
removes it.

This stack approach also solves the possible race condition of a filename
being passed to unlinkd but being in use again by a new object before the
actual unlink() happens.

Arjan
Received on Thu Apr 03 1997 - 11:12:02 MST