From: Roman Mamedov <rm@romanrm.net>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Provide a better free space estimate on RAID1
Date: Sun, 9 Feb 2014 15:20:00 +0600 [thread overview]
Message-ID: <20140209152000.209756de@natsu> (raw)
In-Reply-To: <pan$e196e$601e36f4$65c8817c$b6141c66@cox.net>
[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]
On Sun, 9 Feb 2014 06:38:53 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> 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!
No reason BTRFS can't work well in a similar simplistic usage scenario.
You seem to insist there is no way around it being "too flexible for its own
good", but all those advanced features absolutely don't *have* to get in the
way of everyday usage for users who don't require them.
> 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.
Congratulations, you broke your df readings on all other filesystems to fix
them on btrfs.
> 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.
I am not sure this would work well in the network share scenario described
earlier, with clients which in the real world are largely Windows-based.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-02-09 9:20 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
2014-02-09 9:20 ` Roman Mamedov [this message]
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=20140209152000.209756de@natsu \
--to=rm@romanrm.net \
--cc=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).