linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).