From: Bill Davidsen <davidsen@tmr.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Adding a smaller drive
Date: Tue, 30 Jun 2009 13:01:58 -0400 [thread overview]
Message-ID: <4A4A4506.1070003@tmr.com> (raw)
In-Reply-To: <20090628194705152.ITZI24524@cdptpa-omta02.mail.rr.com>
Leslie Rhorer wrote:
>>> I have a few questions. Some RAID implementations will simply
>>> refuse to create or grow an array if all the targets are not precisely
>>>
>> the
>>
>>> same size. Clearly this is not the case for mdadm. Not all drives of a
>>> given "size" are actually precisely the same size, however, and I am
>>>
>> using
>>
>>> unpartitioned drives for my RAID systems. What happens if I add a drive
>>> whose apparent physical size is a bit smaller than the device size used
>>>
>> to
>>
>>> create the array?
>>>
>> For RAID 4/5/6, I think it'll be refused.
>>
>
> Do you know if the refusal would include an error message clearly
> indicating why the growth is refused?
>
>
>> You have to shrink the
>> filesystem, and LVM if you use it, then the array, so the used size is
>> no bigger than the new drive - as you've noted, md doesn't mind if it
>> doesn't use all the available space on its constituent devices. If it's
>> a small reduction, as I imagine it would be, and your filesystem
>> supports shrinking, it won't take long to do the the shrinks. Then
>> adding the new drive will be painless. If your filesystem won't shrink -
>> and some (many?) won't - I suspect you're scuppered.
>>
>
> I'm no longer using LVM on any of the servers, and I've converted to
> XFS on RAID 5 and RAID 6 arrays. At this time XFS does not support
> shrinking. I've seen some chatter on the web about 3rd party utilities
> which might make it possible.
>
> For growing an array, this would be a bit of a pain, but probably
> not a show stopper. Even for a failed drive I could probably just send the
> new drive back and purchase a different model whose real size is as large or
> larger than the extant drives. The problem is, waiting that long for a new
> drive or doing anything significant (like multiple shrinks!) to a partially
> failed array sends shivers up my spine.
>
> I may have to rethink my position on using raw drives. If I
> partition the drives, I can make the partition a bit smaller than the whole
> drive, allowing for the addition of a future drive whose size is a bit off.
> I hate to waste space, but being stuck with an undersized or limping array
> is worse.
>
Some manufacturers use the HPA (host protected area) to reduce the size
available to the user. You will see reference to this in the dmesg
output. There is a tool to let you see/set HPA, but I can't put my hand
on the info right now, the one I have is out of date, so I won't mention it.
--
Bill Davidsen <davidsen@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one error occurs during
wildcard (glob) expansion.
next prev parent reply other threads:[~2009-06-30 17:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-28 18:31 Adding a smaller drive Leslie Rhorer
2009-06-28 19:05 ` John Robinson
2009-06-28 19:47 ` Leslie Rhorer
2009-06-28 21:09 ` John Robinson
2009-06-28 21:22 ` Leslie Rhorer
2009-06-28 22:52 ` John Robinson
2009-06-28 23:07 ` John Robinson
2009-06-29 10:05 ` Goswin von Brederlow
2009-07-01 4:16 ` Leslie Rhorer
2009-06-28 21:33 ` Martin K. Petersen
2009-06-28 21:49 ` Martin K. Petersen
2009-06-28 22:33 ` Mikael Abrahamsson
2009-06-28 22:51 ` Martin K. Petersen
2009-06-28 23:37 ` Mikael Abrahamsson
2009-06-28 23:43 ` Martin K. Petersen
2009-06-28 23:57 ` Mikael Abrahamsson
2009-07-01 4:12 ` Leslie Rhorer
2009-07-01 5:25 ` Martin K. Petersen
2009-07-03 15:46 ` Leslie Rhorer
2009-07-06 0:05 ` Martin K. Petersen
2009-07-07 3:15 ` Leslie Rhorer
2009-06-28 23:54 ` John Robinson
2009-06-29 0:02 ` Mikael Abrahamsson
2009-06-29 10:07 ` Goswin von Brederlow
2009-06-29 14:45 ` Martin K. Petersen
2009-07-03 16:12 ` Leslie Rhorer
2009-07-03 17:23 ` Billy Crook
2009-07-04 14:59 ` Bill Davidsen
2009-07-04 15:20 ` John Robinson
2009-07-05 22:03 ` Leslie Rhorer
2009-07-05 22:12 ` John Robinson
2009-07-07 2:57 ` Leslie Rhorer
2009-06-30 17:01 ` Bill Davidsen [this message]
2009-06-30 18:22 ` Greg Freemyer
2009-07-01 18:53 ` Bill Davidsen
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=4A4A4506.1070003@tmr.com \
--to=davidsen@tmr.com \
--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 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.