On Mon, Dec 14, 2015 at 6:31 PM, Henk Slager <eye1tm@xxxxxxxxx> wrote: > [...] >>> > 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. # btrfs fi defrag -r -clzo /daten I meant. -- 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
