All of lore.kernel.org

* Re: Is there a "make hole" (truncate in middle) syscall?
From: Rob Landley @ 2003-12-15 11:52 UTC (permalink / raw)
  To: Vladimir Saveliev; +Cc: linux-kernel
In-Reply-To: <1071482402.11042.36.camel@tribesman.namesys.com>

On Monday 15 December 2003 04:00, Vladimir Saveliev wrote:

> > Truncate doesn't look at the contents of the file, it just frees the
> > space regardless of what the data was.  (It doesn't have to load the
> > contents of the blocks into memory and look at them in order to make the
> > file's length shorter in the metadata and de-allocate those blocks.)
> >
> > What was suggested a bit earlier was automatically looking at the
> > contents of the data being written to disk, and not allocating actual
> > blocks if the data is all zeroes.  (A bit like looking at pages of memory
> > and copy-on-write aliasing them to the zero page whenever the page is
> > entirely zeroes.)
> >
> > Truncate doesn't do any of that.  Truncate only plays with metadata, and
> > doesn't care about the contents of the file.
>
> I thought we are talking about something which would allow to create
> holes inside of non sparse file

Yes.  With a syscall that says "from here, to here, punch hole".

The earlier suggestion I was disagreeing with would automatically create holes 
in any file that wrote a sufficiently large range of zero bytes.  Hence the 
cache poisoning and general defeating the purpose of DMA and such.  Neither 
truncate, nor a punch syscall, would mess with the normal "write" path 
(beyond locking so write and truncate/punch didn't stomp each other).

Rob

^ permalink raw reply