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?
signature.asc
Description: Digital signature
