On Jul 19, 2014, at 2:58 PM, Marc Joliet <mar...@gmx.de> wrote: > Am Sat, 19 Jul 2014 22:10:51 +0200 > schrieb Marc Joliet <mar...@gmx.de>: > > [...] >> Another random idea: the number of errors decreased the second time I ran >> balance (from 4 to 2), I could run another full balance and see if it keeps >> decreasing. > > Well, this time there were still 2 ENOSPC errors. But I can show the df > output > after such an ENOSPC error, to illustrate what I meant with the sudden surge > in total usage: > > # btrfs filesystem df /run/media/marcec/MARCEC_BACKUP > Data, single: total=236.00GiB, used=229.04GiB > System, DUP: total=32.00MiB, used=36.00KiB > Metadata, DUP: total=4.00GiB, used=3.20GiB > unknown, single: total=512.00MiB, used=0.00 > > And then after running a balance and (almost) immediately cancelling: > > # btrfs filesystem df /run/media/marcec/MARCEC_BACKUP > Data, single: total=230.00GiB, used=229.04GiB > System, DUP: total=32.00MiB, used=36.00KiB > Metadata, DUP: total=4.00GiB, used=3.20GiB > unknown, single: total=512.00MiB, used=0.00
I think it's a bit weird. Two options: a. Keep using the file system, with judicious backups, if a dev wants more info they'll reply to the thread; b. Migrate the data to a new file system, first capture the file system with btrfs-image in case a dev wants more info and you've since blown away the filesystem, and then move it to a new btrfs fs. I'd use send/receive for this to preserve subvolumes and snapshots. Chris Murphy-- 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
