On 2015-12-22 04:12, Duncan wrote:
Austin S. Hemmelgarn posted on Mon, 21 Dec 2015 08:36:02 -0500 as
excerpted:
On 2015-12-16 21:09, Christoph Anton Mitterer wrote:
On Tue, 2015-12-15 at 11:00 -0500, Austin S. Hemmelgarn wrote:
nodatacow only [avoids fragmentation] if the file is
pre-allocated, if it isn't, then it still ends up fragmented.
Hmm is that "it may end up fragmented" or a "it will definitely? Cause
I'd have hoped, that if nothing else had been written in the meantime,
btrfs would perhaps try to write next to the already allocated blocks.
If there are multiple files being written, then there is a relatively
high probability that they will end up fragmented if they are more than
about 64k and aren't pre-allocated.
Does the 30-second-by-default commit window (and similarly 30-second-
default dirty-flush-time at the VFS level) modify this at all? It has
been my assumption that same-file writes accumulated during this time
should merge, increasing efficiency and decreasing fragmentation (both
with and without nocow), tho of course further writes outside this 30-
second window will likely trigger it, if other files have been written in
parallel or in the mean time.
I think it does, but not much, and it depends on the workload. I do
notice less fragmentation on the filesystems I increase the commit
window on, and more on ones I decrease it, but the difference is pretty
small as long as you use something reasonable (I've never tested
anything higher than 300, and I rarely go above 60). My guess based on
what the commit window is for (namely, it's the amount of time the log
tree gets updated before forcing a transaction to be committed) would be
that it has less effect if stuff is regularly calling fsync().
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
