On Mon, Dec 14, 2015 at 6:31 PM, Henk Slager <eye...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
