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

[Jörn Engel]

On Fri, 12 December 2003 09:40:31 -0600, Andy Isaacson wrote:
> 
> A related idea was reportedly used in the Venti filesystem, which was
> discussed on linux-kernel back in October; look for the thread
> "Transparent compression in the FS".
> 
> The downsides are pretty substantial (but the upsides are too).  You
> don't know how many blocks are available on the filesystem for you to
> write, because when you write you might not allocate blocks.  And you
> lose disk-streaming-perfomance, because you're going to be seeking all
> over the disk picking up the blocks for your files.

Right - to some degree.  I'm sure many problems can be dealt with, but
it takes a lot of time to sort out the details.  For streaming
performance, I guess in most cases you will get the same performance
because you won't find a single duplicate block in those files.  Two
competing readers should be a much bigger problem.

Still, there are more problems, no doubt.

> > But we should get there some day.  Having 15 nearly identical copies
> > of the kernel on my notebook is a pain and hard links simply have the
> > wrong semantics.
> 
> I don't know about you, but I don't have 15 nearly identical copies of
> the kernel; I have 30 copies that have almost no text in common, and
> certainly have no blocks in common -- they result from independent
> compilations, and the resulting bzImage files are not duplicates.

s/kernel/kernel source/

If it was just the images, I couldn't care less.  But 15x 200-300 Megs
does hurt a bit. :)
grep -r over multiple trees hurts even more, when RAM spills over.

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/