Xavier Bassery <xav...@bartica.org> writes: > On Fri, 18 Apr 2014 23:23:56 -0400 > Michael Welsh Duggan <m...@md5i.com> wrote: > >> Michael Welsh Duggan <m...@md5i.com> writes: >> >> root@maru2:~# /usr/local/src/btrfs-progs/btrfs fi df /mnt/ >> Data, RAID1: total=353.00GiB, used=328.24GiB >> System, single: total=32.00MiB, used=56.00KiB >> Metadata, RAID1: total=4.00GiB, used=1.43GiB > > As Chris Murphy noted, your "System" chunk still reported as "single" > is likely the issue here. This reminds me of a bug i stumbled upon > once: https://bugzilla.kernel.org/show_bug.cgi?id=60594 > > Have you converted your fs from SINGLE to RAID-1 profile by running a > balance?
Yes, I did. And I think I was still on 3.10 or 11 when this happened. > This conversion bug should no longer occur with the patch "Btrfs: stop > refusing the relocation of chunk 0" which has been merged since 3.12. > But chances are that you've converted your fs with an older kernel > without that patch. While Ilya Dryomov investigated the issue on my > system, we managed to work around this by using a patched module that > ignored the safety measure refusing to mount rw in this case. > > I still have the patch, but i think the safest way and only other > option would be to copy the data from your ro fs and recreate it from > scratch. Doing so with recent btrfs progs (v3.12 or newer) you'll > benefit from the new default metadata blocksize of 16KB that should > increase performance. Right. *sigh* A pain, but needs must, and all that. Thanks for your help. -- Michael Welsh Duggan (m...@md5i.com) -- 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
