On Sun, Jun 15, 2014 at 11:31:07PM +0200, Martin Steigerwald wrote:
> Am Samstag, 14. Juni 2014, 02:53:20 schrieb Duncan:
> > > I am reaching the conclusion that fallocate is not the problem. The
> > > fallocate increase the filesize of about 8MB, which is enough for some
> > > logging. So it is not called very often.
> > 
> > But... 
> > 
> > If a file isn't (properly[1]) set NOCOW (and the btrfs isn't mounted with 
> > nodatacow), then an fallocate of 8 MiB will increase the file size by 8 
> > MiB and write that out.  So far so good as at that point the 8 MiB should 
> > be a single extent.  But then, data gets written into 4 KiB blocks of 
> > that 8 MiB one at a time, and because btrfs is COW, the new data in the 
> > block must be written to a new location.
> > 
> > Which effectively means that by the time the 8 MiB is filled, each 4 KiB 
> > block has been rewritten to a new location and is now an extent unto 
> > itself.  So now that 8 MiB is composed of 2048 new extents, each one a 
> > single 4 KiB block in size.
> 
> I always thought that the whole point of fallocate is that it *doesn´t* write 
> out anything, but just reserves the space. Thus I don´t see how COW can have 
> any adverse effect here.

   Exactly. fallocate, as I understand it, says, "I'm going to write
[this much] data at some point soon; you may want to allocate that
space in a contiguous manner right now to make the process more
effcient". The space is not a formal part of the file data and so
doesn't need a CoW operation when it's first written to.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
     --- If the first-ever performance is the première,  is the ---     
                  last-ever performance the derrière?