[lkml]   [2003]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Is there a "make hole" (truncate in middle) syscall?
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.


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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.064 / U:5.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site