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. > The only reason I'm really even looking at the fragmentation > issue is because running the defragment (with varying sizes of > "-t" which I'm not sure why that's even necessary) seemed > to force btrfs to move segments around and let me rebalance > more block groups. I don't even care if the files are defragged, > I just want them all in the RAID1 profile. Hopefully if I move > each file out to some other FS like /dev/shm and then back > it will work, I just gotta hack a script together to do so.
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. 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
