From: Michael Tokarev <mjt@tls.msk.ru>
To: maurice <mhilarius@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: mdadm striped parity RAID with Advanced Format drives
Date: Sat, 23 Jul 2011 11:11:05 +0400 [thread overview]
Message-ID: <4E2A7409.60508@msgid.tls.msk.ru> (raw)
In-Reply-To: <4E2A40AC.8080107@gmail.com>
23.07.2011 07:31, maurice wrote:
> On 7/21/2011 5:18 AM, Stan Hoeppner wrote:
>> ..Ok. Pol, keep in mind that all drives must be identical size when
>> creating an array on raw disks.
> That always makes me nervous.
And this is not really correct statement.
If you want to be sure, use --size=xxx argument when creating the
array, and specify a size smaller than size of your drives. This
way, you can avoid possible problems with drive size fluctuations
and different size of a replacement drives from another manufacturer.
Also, the "fluctuations" - i mean, several drives in the same batch
may have slightly different size - will be masked out by mdadm itself,
due to rounding to chunk size.
Just use a few gigs less than your drive size is. Maybe the resulting
size will be a nice power-of-two value, as well.
> I have seen the case before where a drive has been "kicked out" and when
> you go to add it back, it is refused as "too small"
> Grown defects have shrunk the device.
This CAN NOT HAPPEN. Drive never changes its size. Newly
discovered defects gets remapped to _reserved_ space, not to
a space taken from other data. If the drive runs out of
reserved space (but you should replace it WAY before that),
it will stop remapping sectors.
> I find it is safer to make one big partition on each device, and make
> this a bit smaller than the device.
That works too, ofcourse. This way, it might be a bit easier to
identify your drives too - for example, you can use GPT partition
table there with proper labels for your partition.
/mjt
next prev parent reply other threads:[~2011-07-23 7:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201107211011.40151.polhallen@fuckaround.org>
2011-07-21 10:26 ` mdadm striped parity RAID with Advanced Format drives Stan Hoeppner
2011-07-21 10:27 ` Mikael Abrahamsson
2011-07-21 11:18 ` Stan Hoeppner
2011-07-21 11:23 ` Mikael Abrahamsson
2011-07-23 3:31 ` maurice
2011-07-23 7:11 ` Michael Tokarev [this message]
2011-07-23 15:38 ` maurice
2011-07-23 15:58 ` Mikael Abrahamsson
2011-07-23 18:03 ` maurice
2011-07-25 8:41 ` Nikolay Kichukov
2011-07-25 18:57 ` Michael Tokarev
2011-07-21 10:46 ` Pol Hallen
2011-07-22 7:13 ` Luca Berra
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=4E2A7409.60508@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-raid@vger.kernel.org \
--cc=mhilarius@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.