On 10 December 2014 at 00:13, Robert White <rwhite@xxxxxxxxx> wrote: > On 12/09/2014 02:29 PM, Patrik Lundquist wrote: >> >> Label: none uuid: 770fe01d-6a45-42b9-912e-e8f8b413f6a4 >> Total devices 1 FS bytes used 1.35TiB >> devid 1 size 2.73TiB used 1.36TiB path /dev/sdc1 >> >> >> Data, single: total=1.35TiB, used=1.35TiB >> System, single: total=32.00MiB, used=112.00KiB >> Metadata, single: total=3.00GiB, used=1.55GiB >> GlobalReserve, single: total=512.00MiB, used=0.00B > > > Are you trying to convert a filesystem on a single device/partition to RAID > 1? Not yet. I'm stuck at the full balance after the conversion from ext4. I haven't added the disks for RAID1 and might need them for starting over instead. A balance with -musage=100 -dusage=99 works but a full fails. It would be nice to nail the bug since the fs passes btrfs check and it seems to be a clear ENOSPC bug. I don't know how to interpret the space_info error. Why is only 4773171200 (4,4GiB) free? Can I inspect block group 1821099687936 to try to find out what makes it problematic? BTRFS info (device sdc1): relocating block group 1821099687936 flags 1 BTRFS error (device sdc1): allocation failed flags 1, wanted 2013265920 BTRFS: space_info 1 has 4773171200 free, is not full BTRFS: space_info total=1494648619008, used=1489775505408, pinned=0, reserved=99700736, may_use=2102390784, readonly=241664 > P.S. you should re-balance your System and Metadata as "DUP" for now. Two > copies of that stuff is better than one as right now you have no real > recovery path for that stuff. If you didn't make that change on purpose it > probably got down-revved from DUP automagically when you tired to RAID it. Good point. Maybe btrfs-convert should do that by default? I don't think it has ever been DUP. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
