Messages in this thread | | | Date | Fri, 12 Dec 2003 17:03:25 +0100 | From | Jörn Engel <> | Subject | Re: 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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |