Re: Is there a "make hole" (truncate in middle) syscall?

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Fri, 12 December 2003 07:39:25 -0600, Rob Landley wrote:
> On Friday 12 December 2003 06:55, Jörn Engel wrote:
> >
> > Yes, the obvious and stupid implementation has a ton of problems.
> > Most likely the right approach is some sort of background deamon
> > (garbage collector, defragmenter, journald, whatever you may call it)
> > that does exacly this even after the fact for the last unchecked
> > writes.  Asyncronous under load, possibly even synchronous when almost
> > idle.
> 
> Actually, I'd planned on implementing a cron job that could do it.  We're 
> talking a dozen lines of Python code (which can be optimized to only look at 
> files with timestamps since the last time it ran).  And doesn't need anything 
> from the kernel but the syscall...

...and it sucks.  Same problem as with updatedb - 99% of all work is
bogus, but you don't know which 99%, because the one knowing about it,
the kernel, doesn't tell you a thing.

Maybe a simple notification mechanism would sufficiently solve this as
well, so all the rest can be done in userspace.  Basically a file with
a simple format like this:
#path	offset	len
/tmp/foo	0	12

Meaning that bytes 0-11 of /tmp/foo have changed in whatever way.

Something like that, the details don't matter too much.

Jörn

-- 
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon