linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Provide a better free space estimate on RAID1
Date: Sun, 9 Feb 2014 06:38:53 +0000 (UTC)	[thread overview]
Message-ID: <pan$e196e$601e36f4$65c8817c$b6141c66@cox.net> (raw)
In-Reply-To: 20140209041050.529ff6f9@natsu

Roman Mamedov posted on Sun, 09 Feb 2014 04:10:50 +0600 as excerpted:

> If you need to perform a btrfs-specific operation, you can easily use
> the btrfs-specific tools to prepare for it, specifically use "btrfs fi
> df" which could give provide every imaginable interpretation of free
> space estimate and then some.
> 
> UNIX 'df' and the 'statfs' call on the other hand should keep the
> behavior people are accustomized to rely on since 1970s.

Which it does... on filesystems that only have 1970s filesystem features. 
=:^)

RAID or multi-device filesystems aren't 1970s features and break 1970s 
behavior and the assumptions associated with it.  If you're not prepared 
to deal with those broken assumptions, don't.  Use mdraid or dmraid or lvm 
or whatever to combine your multiple devices into one logical devices as 
presented, and put your filesystem (either traditional filesystem, or 
even btrfs using traditional single-device functionality) on top of the 
single device the layer beneath the filesystem presents.  Problem solved! 
=:^)

Note that df only lists a single device as well, not the multiple 
component devices of the filesystem.  That's broken functionality by your 
definition, too, and again, using some other layer like lvm or mdraid to 
present multiple devices as a single virtual device, with a traditional 
single-device filesystem layout on top of that single device... solves 
the problem!


Meanwhile, what I've done here is use one of df's commandline options to 
set its block size to 2 MiB, and further used bash's alias functionality 
to setup an alias accordingly:

alias df='df -B2M'

$ df /h
Filesystem     2M-blocks  Used Available Use% Mounted on
/dev/sda6          20480 12186      7909  61% /h

$ sudo btrfs fi show /h
Label: hm0238gcnx+35l0  uuid: ce23242a-b0a9-423f-a9c3-7db2729f48d6
        Total devices 2 FS bytes used 11.90GiB
        devid    1 size 20.00GiB used 14.78GiB path /dev/sda6
        devid    2 size 20.00GiB used 14.78GiB path /dev/sdb6

$ sudo btrfs fi df /h
Data, RAID1: total=14.00GiB, used=11.49GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=768.00MiB, used=414.94MiB


On btrfs such as the above I can read the 2M blocks as 1M and be happy.  
On btrfs such as my /boot, which aren't raid1 (I have two separate 
/boots, one on each device, with grub2 configured separately for each to 
provide a backup), or if I df my media partitions still on reiserfs on 
the old spinning rust, I can either double the figures DF gives me, or 
add a second -B option at the CLI, overriding the aliased option.

If I wanted something fully automated, it'd be easy enough to setup a 
script that checked what filesystem I was df-ing, matched that against a 
table of filesystems to preferred df block sizes, and supplied the 
appropriate -BxX option accordingly.  As I guess most admins after a few 
years, I've developed quite a library of scripts/aliases for various 
things I do routinely enough to warrant it, and this would be just one 
more joining the list. =:^)


But of course it's your system in question, and you can patch btrfs to 
output anything you like, in any format you like.  No need to bother with 
df's -B option if you'd prefer to patch the kernel instead.  Me, I'll 
stick to the -B option.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  parent reply	other threads:[~2014-02-09  6:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 20:15 Provide a better free space estimate on RAID1 Roman Mamedov
2014-02-06  7:38 ` Brendan Hide
2014-02-06 12:45   ` Roman Mamedov
2014-02-06 19:54     ` Goffredo Baroncelli
2014-02-07  4:40       ` Roman Mamedov
2014-02-07  5:30         ` Chris Murphy
2014-02-07  6:08           ` Roman Mamedov
2014-02-07 18:44             ` Chris Murphy
2014-02-08 21:46               ` Kai Krakow
2014-02-08 11:21             ` Roman Mamedov
2014-02-07 10:02           ` Martin Steigerwald
2014-02-08 21:50             ` Kai Krakow
2014-02-08 15:46         ` Goffredo Baroncelli
2014-02-08 16:36         ` [PATCH][V2] " Goffredo Baroncelli
2014-02-09 17:20         ` [PATCH][V3] Provide a better free space estimate [was]Re: " Goffredo Baroncelli
2014-02-07 14:05       ` Frank Kingswood
2014-02-06 20:21 ` Josef Bacik
2014-02-07 20:32   ` Kai Krakow
2014-02-08 11:33     ` Roman Mamedov
2014-02-08 11:46       ` Hugo Mills
2014-02-08 21:35         ` Kai Krakow
2014-02-08 22:10           ` Roman Mamedov
2014-02-08 22:45             ` cwillu
2014-02-08 23:27               ` Kai Krakow
2014-02-08 23:32             ` Kai Krakow
2014-02-09  1:08               ` Roman Mamedov
2014-02-09  9:39                 ` Kai Krakow
2014-02-09  6:38             ` Duncan [this message]
2014-02-09  9:20               ` Roman Mamedov
2014-02-10  0:02                 ` Duncan
2014-02-10  9:14                   ` Roman Mamedov
2014-02-09  9:37               ` Kai Krakow
2014-02-08 23:17       ` Kai Krakow
2014-02-09  1:55         ` Roman Mamedov
2014-02-09  2:21           ` Chris Murphy
2014-02-09  2:29             ` 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='pan$e196e$601e36f4$65c8817c$b6141c66@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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).