Le jeu. 30 janv. 2020 à 20:53, Matt Corallo <kernel@xxxxxxxxxxx> a écrit :
>
> This is a pretty critical regression for me. I have a few applications that regularly check space available and exit if they find low available space, as well as a number of applications that, eg, rsync small files, causing this bug to appear (even with many TB free). It looks like the suggested patch isn’t moving towards stable, is there some other patch we should be testing?
I was migrating some data over to a new Fedora 31 server with btrfs
when dnf complained that my disk were full, despite having 2.61TiB
unallocated
Once a new kernel with a fix is available Fedora systems will need
some manual work to recover.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
installing package libev-4.27-1.fc31.x86_64 needs 160KB on the / filesystem
...
# uname -r
5.4.7-200.fc31.x86_64
# LANG=C df -hT /
Filesystem Type Size
Used Avail Use% Mounted on
/dev/mapper/luks-17a54b4f-58b1-447f-a1e2-f927503936f2 btrfs 3.7T
1.1T 0 100% /
# btrfs fi usage -T /
Overall:
Device size: 3.63TiB
Device allocated: 1.03TiB
Device unallocated: 2.61TiB
Device missing: 0.00B
Used: 1.02TiB
Free (estimated): 2.61TiB (min: 1.31TiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Data
Metadata System
Id Path RAID0
RAID1 RAID1 Unallocated
-- ----------------------------------------------------- ---------
-------- -------- -----------
1 /dev/mapper/luks-17a54b4f-58b1-447f-a1e2-f927503936f2 522.00GiB
3.00GiB 8.00MiB 1.30TiB
2 /dev/mapper/luks-ee555ebd-59ca-4ed8-9d68-7c3faf6e6a25 522.00GiB
3.00GiB 8.00MiB 1.30TiB
-- ----------------------------------------------------- ---------
-------- -------- -----------
Total 1.02TiB
3.00GiB 8.00MiB 2.61TiB
Used 1.02TiB
2.75GiB 96.00KiB
The good news is that I saw that I messed up my kickstart installed
and ended up with RAID0 for data
>
> > On Jan 30, 2020, at 18:12, Martin Steigerwald <martin@xxxxxxxxxxxx> wrote:
> >
> > Remi Gauvin - 30.01.20, 22:20:47 CET:
> >>> On 2020-01-30 4:10 p.m., Martin Steigerwald wrote:
> >>> I am done with re-balancing experiments.
> >>
> >> It should be pretty easy to fix.. use the metadata_ratio=1 mount
> >> option, then write enough to force the allocation of more data
> >> space,,
> >>
> >> In your earlier attempt, you wrote 500MB, but from your btrfs
> >> filesystem usage, you had over 1GB of allocated but unused space.
> >>
> >> If you wrote and deleted, say, 20GB of zeroes, that should force the
> >> allocation of metatada space to get you past the global reserve size
> >> that is causing this bug,, (Assuming this bug is even impacting you.
> >> I was unclear from your messages if you are seeing any ill effects
> >> besides the misreporting in df.)
> >
> > I thought more about writing a lot of little files as I expect that to
> > use more metadata, but… I can just work around it by using command line
> > tools instead of Dolphin to move data around. This is mostly my music,
> > photos and so on filesystem, I do not change data on it very often, so
> > that will most likely work just fine for me until there is a proper fix.
> >
> > So do need to do any more things that could potentially age the
> > filesystem. :)
> >
> > --
> > Martin
> >
> >
>
