2.2.5pre1: unlink design flaw

[Mike Gerdts]

On Thu, 2002-06-13 at 12:26, Cole, Timothy D. wrote:
> > -----Original Message-----
> > From: Mike Gerdts [mailto:Michael.Gerdts at alcatel.com]
> > A similar solution could be used here.  The equivalent of the .OLD
> > directory could be something that is not exported by samba.  If an
> > unlink() fails because of ETXTBUSY, rename() could be used to move it
> > out of the shared directory to a directory that is monitored by a
> > "deleted file reaper".
> 
> The way NFS deals with this is typically for the server to rename unlinked
> but open files to .nfs.somethingorother.

But it too relies upon a find through the file system to clean up any
droppings that are left.  From Solaris 9's standard root crontab:

	15 3 * * 0 /usr/lib/fs/nfs/nfsfind

Since *nothing* is ever happening on a system at 3:15 in the morning
this seems like a completely reasonable thing to do.  Except for the
fact that your samba file system cleaner is running, your netscape cache
cleaner, the thing that goes around and "fixes" world writable
directories, and backups.  Now why is it that my full backups on Sunday
morning are not completing on time?  (Sorry... just had a flashback to
when my big file servers will Sparc 20's with 16 5400 RPM 5 1/4" 9 gig
drives, software RAID, 1 50 MHz processor, and 64 meg of RAM.)

If I were writing NFS server code, I would make it do the same thing
that I suggested for Samba.  Actually, if I was running a Linux NFS
server and was seeing performance problems that were aggrevated by
nfsfind, I would strongly consider implementing the change myself.

Mike