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

Jörn Engel
2003-12-12T14:00:13Z

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