From: NeilBrown <neilb@suse.de>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: shown disk sizes
Date: Wed, 24 Jul 2013 08:27:01 +1000 [thread overview]
Message-ID: <20130724082701.006f5fab@notabene.brown> (raw)
In-Reply-To: <1374617431.5348.21.camel@fermat.scientia.net>
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
On Wed, 24 Jul 2013 00:10:31 +0200 Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Wed, 2013-07-24 at 06:57 +1000, NeilBrown wrote:
> > New feature in 3.3 is that when you reshape (e.g.) a RAID5 to a RAID6 it can
> > do so without using a "backup file" - which is are a pain to work with and
> > slow things down a lot.
> > What it does instead is move the "data_offset" towards the start of the
> > device. That way it is never writing onto live data, and so no backup is
> > needed.
> So you are stealing my precious space, which I was paying soo much money
> for?! ;-)
>
> Seriously,... sounds like a good idea... :)
> But why does it also increase the "gap" at the end? Guess the whole
> "gap" at the end thingy is something we will never ever really get rid
> of, will we? I mean it's no problem because of some missing sectors...
> it just makes like more complicated when doing manual geometry
> calculations...
The "gap at the end" is due to clumsy coding that I indicated earlier that I
would try to find time to tidy up.
>
>
> While talking about data_offset... is it planned to implement a way to
> add a way to specify the data_offset manually and/or specify a
> data_offset_offset (i.e. a additional offset to what mdadm would have
> autodetected... similar as LVM allows?
You mean like a "--data-offset" option to --create and --grow? Yes mdadm
3.3 has that.
>
> I mean the practical relevance is probably not that much... but manual
> specification would probably needed whenever you have some more complex
> block layer (e.g. LVM), another MD or a hardware RAID below MD... and
> you want to align to the stripes... or unusual large chunk sizes...
>
> I've seen that you have some branch where you can specify the offset for
> each device... but... guess that was only for some guys to do recovery
> works?!
It is now part of mainline.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2013-07-23 22:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 14:37 shown disk sizes Christoph Anton Mitterer
2013-07-17 23:43 ` NeilBrown
2013-07-18 0:39 ` Christoph Anton Mitterer
2013-07-18 7:35 ` Mikael Abrahamsson
2013-07-23 16:26 ` Christoph Anton Mitterer
2013-07-23 17:12 ` Mikael Abrahamsson
2013-07-23 17:22 ` Christoph Anton Mitterer
2013-07-23 20:57 ` NeilBrown
2013-07-23 22:10 ` Christoph Anton Mitterer
2013-07-23 22:27 ` NeilBrown [this message]
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=20130724082701.006f5fab@notabene.brown \
--to=neilb@suse.de \
--cc=calestyo@scientia.net \
--cc=linux-raid@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).