From: Goffredo Baroncelli <kreijack@libero.it>
To: Roman Mamedov <rm@romanrm.net>, kreijack@inwind.it
Cc: Brendan Hide <brendan@swiftspirit.co.za>, linux-btrfs@vger.kernel.org
Subject: Re: Provide a better free space estimate on RAID1
Date: Sat, 08 Feb 2014 16:46:15 +0100 [thread overview]
Message-ID: <52F65147.2080505@libero.it> (raw)
In-Reply-To: <20140207104005.7bd1438a@natsu>
On 02/07/2014 05:40 AM, Roman Mamedov wrote:
> On Thu, 06 Feb 2014 20:54:19 +0100
> Goffredo Baroncelli <kreijack@libero.it> wrote:
>
[...]
Even I am not entirely convinced, I update the Roman's PoC in order
to take in account all the RAID levels.
I performed some tests with 7 48.8GB disks. Here my "df" results
Profile: single
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 342G 512K 340G 1% /mnt/btrfs1
Profile: raid1
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 342G 1.3M 147G 1% /mnt/btrfs1
Profile: raid10
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 342G 2.3M 102G 1% /mnt/btrfs1
Profile: raid5
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 342G 2.0M 291G 1% /mnt/btrfs1
Profile: raid6
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 342G 1.8M 243G 1% /mnt/btrfs1
Note that RAID1 can only uses 6 disks; raid 10 only four, but I think that it
is due to a previous bug.
Still the mixing mode (data and metadata raid in the same chunk) is unsupported
below my patch.
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index d71a11d..e5c58b3 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1485,6 +1485,12 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
} else if (type & BTRFS_BLOCK_GROUP_RAID10) {
min_stripes = 4;
num_stripes = 4;
+ } else if (type & BTRFS_BLOCK_GROUP_RAID5) {
+ min_stripes = 3;
+ num_stripes = nr_devices;
+ } else if (type & BTRFS_BLOCK_GROUP_RAID6) {
+ min_stripes = 4;
+ num_stripes = nr_devices;
}
if (type & BTRFS_BLOCK_GROUP_DUP)
@@ -1561,8 +1567,30 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
if (devices_info[i].max_avail >= min_stripe_size) {
int j;
u64 alloc_size;
+ int k;
- avail_space += devices_info[i].max_avail * num_stripes;
+ /*
+ * Depending by the RAID profile, we use some
+ * disk space as redundancy:
+ * RAID1, RAID10, DUP -> half of space used as redundancy
+ * RAID5 -> 1 stripe used as redundancy
+ * RAID6 -> 2 stripes used as redundancy
+ * RAID0,LINEAR -> no redundancy
+ */
+ if (type & BTRFS_BLOCK_GROUP_RAID1) {
+ k = num_stripes >> 1;
+ } else if (type & BTRFS_BLOCK_GROUP_DUP) {
+ k = num_stripes >> 1;
+ } else if (type & BTRFS_BLOCK_GROUP_RAID10) {
+ k = num_stripes >> 1;
+ } else if (type & BTRFS_BLOCK_GROUP_RAID5) {
+ k = num_stripes-1;
+ } else if (type & BTRFS_BLOCK_GROUP_RAID6) {
+ k = num_stripes-2;
+ } else { /* RAID0/LINEAR */
+ k = num_stripes;
+ }
+ avail_space += devices_info[i].max_avail * k;
alloc_size = devices_info[i].max_avail;
for (j = i + 1 - num_stripes; j <= i; j++)
devices_info[j].max_avail -= alloc_size;
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-02-08 15:46 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 [this message]
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
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=52F65147.2080505@libero.it \
--to=kreijack@libero.it \
--cc=brendan@swiftspirit.co.za \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
/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).