Hugo Mills posted on Fri, 07 Mar 2014 08:02:13 +0000 as excerpted: > On Fri, Mar 07, 2014 at 01:13:53AM +0000, Michael Russo wrote: >> Duncan <1i5t5.duncan <at> cox.net> writes: >> >> > But if you're not using compression, /that/ can't explain it... >> > >> > >> Ha! Well while that was an interesting discussion of fragmentation, I >> am only using the default mount options here and so no compression. > > I _think_ the problem here is that there may have been some extents > created during the conversion which were over 1 GiB in size (or at least > which run across two or more chunks). This causes problems, because > there's nowhere that they can be written to by the balance -- > which preserves extents -- because none of the allocation units (chunks) > are big enough. > > The defrag operation, by its nature, _doesn't_ preserve extents, > and thus can act to break up the large extents, making it possible to > balance the chunks that the offending extents live on.
Now /that/ would explain the issue, or at least all I've read of it from here. Nice job! =:^) Obviously >1 GB files break/fragment on 1-gig data-chunk lines when (re)written on btrfs, since that's the biggest allocation unit btrfs has, and at least once the filesystem has been (near) full once, btrfs is extremely unlikely to be able to place those gig-chunks contiguously, thus triggering the issue. Meanwhile, the move-to-tmpfs-and-back should indeed break up those >1-gig blocks too, since the that would force a rewrite and thus a reallocation, which would then follow btrfs 1-gig-chunk rules. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
