[...] >> > merkaba:~> btrfs fi sh /daten >> > Label: 'daten' uuid: […] >> > >> > Total devices 1 FS bytes used 227.23GiB >> > devid 1 size 230.00GiB used 230.00GiB path [...] >> > merkaba:~> btrfs fi df /daten >> > Data, single: total=228.99GiB, used=226.79GiB >> > System, single: total=4.00MiB, used=48.00KiB >> > Metadata, single: total=1.01GiB, used=449.50MiB >> > GlobalReserve, single: total=160.00MiB, used=0.00B
If this is still the fill-level of the storage device, then also with 4.4-rcX and new enough tools it will fail I think. AFAIK, scrub does writes (in metadata?) so I think a non-read-only scrub command can't allocate space. See all other comments/threads w.r.t. allocated / free space. Especially an fs of this size, I would keep ~10% free on 'device-level' ( 227.23GiB would need to be 207.00GiB ) and also ~10% on 'chunk-level' ( 226.79GiB would need to be 186.30GiB ). Assuming you don't have snapshots, a btrfs fi defrag -r /daten might give some more room short-term, after you just (re)moved files off the fs first. -- 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
