Re: unlinkd ??

On Apr 3, 8:49pm, Arjan de Vet wrote:
} Subject: 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.

Sounds good.

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

But what if unlinkd called truncate() instead of unlink()? I think
this would considerably reduce the amount of I/O.

} 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.

Ouch! That would be bad.

                        --- Truck
Received on Thu Apr 03 1997 - 16:29:36 MST