Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.unix.wizards
Subject: Re: sticky bit (really, unfragmenting files)
Message-ID: <293@microsoft.UUCP>
Date: 18 Jan 89 00:23:09 GMT
References: <18016@adm.BRL.MIL> <14750@cisunx.UUCP> <1359@mtunb.ATT.COM> <314@twwells.uucp> <8724@alice.UUCP> <18714@santra.UUCP> <5067@b-tech.ann-arbor.mi.us>
Reply-To: w-colinp@microsoft.uucp (Colin Plumb)
Organization: very little
Lines: 22

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) wrote:
> Actually, I've never understood why the kernel didn't have some 
> locking support that would allow a daemon to unfragment the disk 
> during idle times.  

Actually, you don't ever need to lock the file.  Basically, you
find the oldest file that hasn't been unfragged (although adding an
unsettable last-mod-time helps here), allocate a new inode, copy it
to contiguous storage, and then make one magic call, that swaps the
two and deletes the old file if it hasn't been changed since the copy
started, and deletes the new copy if it has changed.

I've been (in the past) involved in writing an FS that provides a background-
cleanup daemon, and this is basically how it works.  Every now and then,
you'll waste effort, but if you start with old files, it's very rare.  And
not locking the files increases the transparency of the operation.

For minumum impact, you need a way to prioritise disk I/O, which I don't
think Unix currently has, but can be hacked into an elevator algorithm.
And you can live without.
-- 
	-Colin (uunet!microsof!w-colinp)