Subject: Re: Multiple-remove?
To: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
From: Paul B Dokas <dokas@cs.umn.edu>
List: tech-kern
Date: 07/20/1996 08:21:39
> Jukka Marin <jmarin@pyy.jmp.fi> sent this to current-users, and it
> reminded me of something I'd been thinking about:
> 
> > I'm having problems with inn (its 'fastrm' program complains about
> > long command lines).
> 
> What was thinking about is fastrm.
> 
> The reason unlink() is so slow is that it has to lock the directory,
> edit it, synchronously write it, and unlock it...repeated for every
> entry being unlinked.  Cacheing helps some, otherwise fastrm wouldn't
> be the win it is, but there's lots more that could be done.
> 
> What do people think of a syscall that takes a path to a directory, and
> a list of names in that directory, and unlinks them all?  The win, of
> course, is that it can do only one lock/unlock and one synchronous
> write for the whole batch.

  [...]

> Comments?  Is there any way to get comparably good behavior without
> ripping namei apart?  (Short of mounting the filesystem -o async, of
> course, which would get much of the same benefit, but is significantly
> more dangerous.)

A new syscall is probably overkill.  A much better solution would be to
implement soft updates (async metadata writes that preserve file system
consistency).  I've got a paper around here somewhere that details an
(encumbered) BSD 4.3 implementation.  It is long on details and implementation
notes.

The main advantage of soft updates is that they would improve FS performance
for all programs and not just inn.  Not to mention that it fights against
cluttering up the syscall interface.


I'll go dig up that paper and email out it's title, author, etc.

Paul
-- 
Paul Dokas                     pbd@winternet.com or dokas@cs.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."