Re: ENOSPC errors during balance

[Marc Joliet <marcec@gmx.de>]

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

Am Sun, 20 Jul 2014 02:39:27 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Chris Murphy posted on Sat, 19 Jul 2014 11:38:08 -0600 as excerpted:
> 
> > I'm not sure of the reason for the "BTRFS info (device sdg2): 2 enospc
> > errors during balance" but it seems informational rather than either a
> > warning or problem. I'd treat ext4->btrfs converted file systems to be
> > something of an odd duck, in that it's uncommon, therefore isn't getting
> > as much testing and extra caution is a good idea. Make frequent backups.
> 
> Expanding on that a bit...
> 
> Balance simply rewrites chunks, combining where possible and possibly 
> converting to a different layout (single/dup/raid0/1/10/5/6[1]) in the 
> process.  The most common reason for enospc during balance is of course 
> all space allocated to chunks, with various workarounds for that if it 
> happens, but that doesn't seem to be what was happening to you
> (Mark J./OP).
> 
> Based on very similar issues reported by another ext4 -> btrfs converter 
> and the discussion on that thread, here's what I think happened:
> 
> First a critical question for you as it's a critical piece of this 
> scenario that you didn't mention in your summary.  The wiki page on
> ext4 -> btrfs conversion suggests deleting the ext2_saved subvolume and 
> then doing a full defrag and rebalance.  You're attempting a full 
> rebalance, but have you yet deleted ext2_saved and did you do the defrag 
> before attempting the rebalance?
> 
> I'm guessing not, as was the case with the other user that reported this 
> issue.  Here's what apparently happened in his case and how we fixed it:

Ah, I actually did, in fact.  I only implicitly said it, though.  Here's what I
wrote:

"After converting the backup partition about a week ago, following the wiki
entry on ext4 conversion, I eventually ran a full balance [...]"

The wiki says to run a full balance (and defragment before that, but that was
sloooooooow, so I didn't do it), *after* deleting the ext4 file system image.
So the full balance was right after doing that :) .

> The problem is that btrfs data chunks are 1 GiB each.  Thus, the maximum 
> size of a btrfs extent is 1 GiB.  But ext4 doesn't have an arbitrary 
> limitation on extent size, and for files over a GiB in size, ext4 extents 
> can /also/ be over a GiB in size.
> 
> That results in two potential issues at balance time.  First, btrfs 
> treats the ext2_saved subvolume as a read-only snapshot and won't touch 
> it, thus keeping the ext* data intact in case the user wishes to rollback 
> to ext*.  I don't think btrfs touches that data during a balance either, 
> as it really couldn't do so /safely/ without incorporating all of the 
> ext* code into btrfs.  I'm not sure how it expresses that situation, but 
> it's quite possible that btrfs treats it as enospc.
> 
> Second, for files that had ext4 extents greater than a GiB, balance will 
> naturally enospc, because even the biggest possible btrfs extent, a full 
> 1 GiB data chunk, is too small to hold the existing file extent.  Of 
> course this only happens on filesystems converted from ext*, because 
> natively btrfs has no way to make an extent larger than a GiB, so it 
> won't run into the problem if it was created natively instead of 
> converted from ext*.
> 
> Once the ext2_saved subvolume/snapshot is deleted, defragging should cure 
> the problem as it rewrites those files to btrfs-native chunks, normally 
> defragging but in this case fragging to the 1 GiB btrfs-native data-chunk-
> size extent size.

Hmm, well, I didn't defragment because it would have taken *forever* to go
through all those hardlinks, plus my experience is that ext* doesn't fragment
much at all, so I skipped that step.  But I certainly have files over 1GB in
size.

On the other hand, the wiki [0] says that defragmentation (and balancing) is
optional, and the only reason stated for doing either is because they "will have
impact on performance".

> Alternatively, and this is what the other guy did, one can find all the 
> files from the original ext*fs over a GiB in size, and move them off-
> filesystem and back AFAIK he had several gigs of spare RAM and no files 
> larger than that, so he used tmpfs as the temporary storage location, 
> which is memory so the only I/O is that on the btrfs in question.  By 
> doing that he deleted the existing files on btrfs and recreated them, 
> naturally splitting the extents on data-chunk-boundaries as btrfs 
> normally does, in the recreation.
> 
> If you had deleted the ext2_saved subvolume/snapshot and done the defrag 
> already, that explanation doesn't work as-is, but I'd still consider it 
> an artifact from the conversion, and try the alternative move-off-
> filesystem-temporarily method.

I'll try this and see, but I think I have more files >1GB than would account
for this error (which comes towards the end of the balance when only a few
chunks are left).  I'll see what "find /mnt -type f -size +1G" finds :) .

> If you don't have any files over a GiB in size, then I don't know... 
> perhaps it's some other bug.
> 
> ---
> [1] Raid5/6 support not yet complete.  Operational code is there but 
> recovery code is still incomplete.

[0] https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

Thanks
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]