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

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

On Fri, 12 December 2003 15:37:42 -0600, Rob Landley wrote:
> On Friday 12 December 2003 08:24, Jörn Engel wrote:
> 
> > > ...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.
> >
> > Actually, updatedb sucks even worse.  The database is notoriously
> > outdated and each run of updatedb has the effect of flushing the
> > cache.  Because of the cache-flushing effect, you cannot even run it
> > with maximum niceness.  Running it still hurts you *afterwards*.
> >
> > Same goes for you userland daemon without kernel support.
> 
> 1) The date optimization, only looking at files newer than the last run, means
> you can avoid looking at 90% of the filesystem.

And how do you figure out the date?  ;)

> 2) If drop-behind ever gets working, life is good for this sort of thing.  If 
> not, there's always O_DIRECT or its replacement (whatever Linus and the 
> oracle guy were arguing about last month)...

Not sure what drop-behind is.  Sounds interesting.

Anyway, what updatedb, userspace defragmenters etc. need is a
notification, what has changed.  Without this notification, they have
to look at everything and figure it out themselves.  Ask the network
people why select doesn't scale too well - updatedb is even worse
because it doesn't even notice that *anything* has changed, much less
what change happened.

O_DIRECT, O_STREAMING or O_WHATEVER is also a different beast.  With
streaming media, there is no way to avoid touching the data in the
first place.  If there was, we could do even better, but there isn't.

For updatedb there is.

Jörn

-- 
When in doubt, punt.  When somebody actually complains, go back and fix it...
The 90% solution is a good thing.
-- Rob Landley