Re: ENOSPC errors during raid1 rebalance

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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?                   

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]