From: Hugo Mills <hugo@carfax.org.uk>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: cwillu <cwillu@cwillu.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs-tools in Debian squeeze-backports?
Date: Mon, 2 Jan 2012 15:14:22 +0000 [thread overview]
Message-ID: <20120102151422.GA27122@carfax.org.uk> (raw)
In-Reply-To: <4F01C6DC.3040609@pocock.com.au>
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
On Mon, Jan 02, 2012 at 04:01:48PM +0100, Daniel Pocock wrote:
> One thing I've already noticed in 2.6.39 (and both versions of the
> tools) is that df results are misleading. E.g. if I run regular df (not
> btrfs fi df), I am seeing the same amount of available space for all
> filesystems. Is there currently a way to see space used by each
> subvolume and snapshot and which kernel and tools versions might be needed?
It's actually not possible in general. Since it's possible to have
different bits of the FS (data vs metadata) with different replication
levels, one byte written to the FS could take up either 1 or 2 bytes
of raw disk storage, and there's no way of predicting what the overall
usage will be, so it's not possible to give an accurate estimate of
free space.
Similarly, if you have a 10G subvolume, and a snapshot of it, then
how much space does each one take up?
If you said 10G, then you're wrong, because the total storage space
for the two together is only 10G.
If, on the basis of that, you said 5G each, you're wrong, because
if you delete one of them, you get no free space back.
If, on the basis of that, you said 0G each, you're wrong, because
if you delete both of them you get 10G of free space back.
The best you can ask is "if I delete this subvolume, how much space
will I get back?", but even that's non-trivial: Arne Jansen is working
on that feature as a side-effect of his quota work, and it will be
coming at some point, but we can't do it right now.
See the FAQ on filesystem usage[1] for how to interpret the btrfs
tools for examining space usage, and the mis-named "sysadmin's
guide"[2] for more horrible details of what's going on underneath.
Hugo.
[1] http://btrfs.ipv5.de/index.php?title=FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F
[2] http://btrfs.ipv5.de/index.php?title=SysadminGuide
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I'm on a 30-day diet. So far I've lost 18 days. ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2012-01-02 15:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 14:29 btrfs-tools in Debian squeeze-backports? Daniel Pocock
2012-01-02 14:43 ` Hugo Mills
2012-01-02 14:55 ` cwillu
2012-01-02 15:01 ` Daniel Pocock
2012-01-02 15:14 ` Hugo Mills [this message]
2012-01-02 16:25 ` (renamed thread) btrfs metrics Daniel Pocock
2012-01-02 16:39 ` Hugo Mills
2012-01-04 11:48 ` Daniel Pocock
2012-01-04 18:46 ` Kok, Auke-jan H
2012-01-05 10:09 ` Daniel Pocock
2015-08-30 12:31 ` (renamed thread) btrfs metrics, free space reporting Daniel Pocock
2015-08-31 2:03 ` Qu Wenruo
2012-01-04 18:05 ` btrfs-tools in Debian squeeze-backports? Jan Schmidt
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=20120102151422.GA27122@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=cwillu@cwillu.com \
--cc=daniel@pocock.com.au \
--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).