From: Christian Kujau <lists@nerdbynature.de>
To: linux-btrfs@vger.kernel.org
Subject: file system full on a single disk?
Date: Mon, 13 Jan 2020 14:18:54 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.99999.375.2001131400390.21037@trent.utfs.org> (raw)
Hi,
I realize that this comes up every now and then but always for slightly
more complicated setups, or so I thought:
============================================================
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/luks-root 825G 389G 0 100% /
# btrfs filesystem show /
Label: 'root' uuid: 75a6d93a-5a5c-48e0-a237-007b2e812477
Total devices 1 FS bytes used 388.00GiB
devid 1 size 824.40GiB used 395.02GiB path /dev/mapper/luks-root
# blockdev --getsize64 /dev/mapper/luks-root | awk '{print $1/1024^3, "GB"}'
824.398 GB
# btrfs filesystem df /
Data, single: total=388.01GiB, used=387.44GiB
System, single: total=4.00MiB, used=64.00KiB
Metadata, single: total=2.01GiB, used=1.57GiB
GlobalReserve, single: total=512.00MiB, used=80.00KiB
============================================================
This is on a Fedora 31 (5.4.8-200.fc31.x86_64) workstation. Where did the
other 436 GB go? Or, why are only 395 GB allocated from the 824 GB device?
I'm running a --full-balance now and it's progressing, slowly. I've seen
tricks on the interwebs to temporarily add a ramdisk, run another balance,
remove the ramdisk again - but that seems hackish.
Isn't there a way to prevent this from happening? (Apart from better
monitoring, so I can run the balance at an earlier stage next time).
Thanks,
Christian.
# btrfs filesystem usage -T /
Overall:
Device size: 824.40GiB
Device allocated: 395.02GiB
Device unallocated: 429.38GiB
Device missing: 0.00B
Used: 388.00GiB
Free (estimated): 435.94GiB (min: 435.94GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 512.00MiB (used: 0.00B)
Data Metadata System
Id Path single single single Unallocated
-- --------------------- --------- -------- -------- -----------
1 /dev/mapper/luks-root 393.01GiB 2.01GiB 4.00MiB 429.38GiB
-- --------------------- --------- -------- -------- -----------
Total 393.01GiB 2.01GiB 4.00MiB 429.38GiB
Used 386.45GiB 1.55GiB 64.00KiB
--
BOFH excuse #326:
We need a licensed electrician to replace the light bulbs in the computer room.
next reply other threads:[~2020-01-13 22:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 22:18 Christian Kujau [this message]
2020-01-13 22:55 ` file system full on a single disk? Chris Murphy
2020-01-13 23:21 ` Christian Kujau
2020-01-13 23:29 ` Chris Murphy
2020-01-13 23:38 ` Christian Kujau
2020-01-13 23:51 ` Chris Murphy
2020-01-13 23:41 ` Chris Murphy
2020-01-14 2:16 ` Christian Kujau
2020-01-14 3:39 ` Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.99999.375.2001131400390.21037@trent.utfs.org \
--to=lists@nerdbynature.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).