I wish i could follow your procedure, but this wasn't an ext conversion.
I made this with mkfs for btrfs with kernel circa 3.8ish
On 09/15/14 20:08, Duncan wrote:
Chris Murphy posted on Mon, 15 Sep 2014 14:54:57 -0600 as excerpted:
I still get enospc after a balance with a filter, and then a regular
balance:
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
Maybe try mount option enospc_debug and retry, see if you get more
information in dmesg.
I'm not sure if a balance in this case wants to create a new data and
metadata chunk (on each device), or if it can start without creating any
chunks. If it wants to create new chunks, it's 1GiB for data, and 256MiB
for metadata. That's 1.256GiB but you only have 1.25GiB unallocated on
each device: size 9.31GiB minus used 8.06GiB.
Another possibility that has hit a few people:
Did you (MM/OP not CM) convert that filesystem from ext* to btrfs? If
so, read on. If not, this doesn't apply so you may skip it.
Assuming such a conversion, did you delete the subvolume containing the
original ext* yet, or not? If not, that may be the problem, because that
subvolume must be left intact in ordered to allow rollback to ext* if
desired. If you know you won't be rolling back, delete the ext* reserved
subvolume as described on the wiki.
Meanwhile, after deleting that subvolume, be sure to complete the defrag
and balance as suggested on the wiki, because failing to do so can lead
to other problems later. Basically, the biggest extent size supported by
btrfs is 1 GiB, the size of a btrfs data chunk, while ext* supports
larger (unlimited size?) extents. Failing to complete the defrag in
particular as suggested can mean large files with extents > 1 GiB in
size, which gives btrfs balance indigestion since it expects to see only
1 GiB or smaller extents. Several folks who converted from ext3/4 have
reported failed balances due to these too large extents, and fixing the
problem later can require manually moving one-by-one all files large
enough to be candidates for the problem (thus files > 1 GiB) out of btrfs
and back in, thus resulting in properly chunk-split extents when the file
is moved back to btrfs. Everyone who has reported this problem so far,
has also reported that the move out and back in process solved the
problem for them, but if there's lots of such files it can be a pain, and
doing the defrag on the formerly ext* files before starting to use the
now btrfs for other things, ESPECIALLY before trying to snapshot affected
subvolumes since that locks the problem in place until those snapshots
are deleted, is definitely preferred. =:^)
--
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
