linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arne Jansen <sensille@gmx.net>
To: Thomas Schmidt <Schmidt-T@gmx.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [RFC] improve space utilization on off-sized raid devices
Date: Thu, 01 Dec 2011 09:55:27 +0100	[thread overview]
Message-ID: <4ED740FF.1010304@gmx.net> (raw)
In-Reply-To: <20111117140625.279050@gmx.net>

On 17.11.2011 15:06, Thomas Schmidt wrote:
> -------- Original-Nachricht --------
>> Datum: Thu, 17 Nov 2011 13:59:26 +0100
>> Von: Arne Jansen <sensille@gmx.net>
>> An: Thomas Schmidt <Schmidt-T@gmx.de>
>> CC: linux-btrfs@vger.kernel.org
>> Betreff: Re: [RFC] improve space utilization on off-sized raid devices
> 
> 
> Consider a 4 dev setup: 3 1TB drives and 1 2TB using -m raid1
> -d raid0: 80% capacity striped 4 way.
> -d single: 100% but no striping.
> My patch: 100% striped 3 way, a good trade imho.
> 
> I don't think such a setup is unlikely enough to ignore, a home user will
> simply buy the drive with the best space/cost whenever he needs space,
> leading exactly to the described situation. Adding a newly bought 2T drive
> to my 3x1T setup, only to see that only half of it can be used would really
> piss me off.
> 
> Note that if the (optional) first "if" is removed I only reduce width if it
> is required to reach 100% capacity. At least thats the intention, it might
> need some tweaking.
> According to the (hackish) simulator I used to test this, typically the
> average stripe width sacrificed on setups of 5+ unmatched devices is below
> 2

As RAID0 is already not a strict 'all disks or none', I like the idea to
have it even more dynamic to reach full optimization. But I'd like to see
some properties conserved:
 a) In case of even size disks, the stripes should always be full size, not
   n - 1
 b) Minor variations in the used space per disk due to metadata chunks should
   not lead to deviation from a)
 c) The algorithms should not give weird results under unconventional setups.
    Some theoretical background would be nice :)

It might well be that your algorithm is already close :)

-Arne

  reply	other threads:[~2011-12-01  8:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17  0:27 [RFC] improve space utilization on off-sized raid devices Thomas Schmidt
2011-11-17  7:42 ` Arne Jansen
2011-11-17 11:53   ` Thomas Schmidt
2011-11-17 12:59     ` Arne Jansen
2011-11-17 14:06       ` Thomas Schmidt
2011-12-01  8:55         ` Arne Jansen [this message]
2012-01-24 17:15           ` THomas Schmidt
2012-01-24 21:01           ` Thomas Schmidt
2011-11-17 18:27       ` Phillip Susi

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=4ED740FF.1010304@gmx.net \
    --to=sensille@gmx.net \
    --cc=Schmidt-T@gmx.de \
    --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).