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

Jörn Engel
2003-12-12T16:03:30Z

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