Adding a smaller drive

Adding a smaller drive

[Leslie Rhorer]

	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?  Does the resync force a smaller device size?  What is the
limit for how much smaller a new drive can be than the smallest extant in
the array?  What if I try to replace a drive in the array with one smaller
than the provisioned device size?  This would apparently shrink the array
some.  I take it in such a scenario I should shrink the filesystem on the
array before replacing the drive (scary!)?  How will I know a-priori this
would be the case?

Re: Adding a smaller drive

[John Robinson]

On 28/06/2009 19:31, 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. 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.

It has to be that way because md can't (currently?) tell whatever's 
layered over it to change itself (though I think (guess) that to some 
extent this may change at some point in the future with some of the 
topology stuff that's been discussed here recently).

I don't know what RAID 0/1/10 would do but I imagine they'd be the same.

Cheers,

John.

RE: Adding a smaller drive

[Leslie Rhorer]

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

Re: Adding a smaller drive

[John Robinson]

On 28/06/2009 20:47, 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?

I don't know about current versions, but I just tried it with loop 
devices on CentOS 5 with mdadm 2.6.4, starting with a 3-member RAID-5 
and trying to add a slightly-too-small 4th, and it's not a helpful error 
message: "mdadm: add new device failed for /dev/loop4 as 3: Invalid 
argument"

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

Yes it is. You can still use raw devices, just give the --size argument 
when creating your array, and it won't use the largest size possible. 
You'll want to work out how many KiB (i.e. 2^10 bytes) there are in a 
drive manufacturer's MB (10^6), GB (10^9) or TB (10^12) and use that as 
appropriate. For example, presumably all manufacturers' 500G drives will 
have at least 500*10^9 bytes of storage on them, and divided by 1024 
that's 488281250.

Cheers,

John.

RE: Adding a smaller drive

[Leslie Rhorer]

> > 	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.
> 
> Yes it is. You can still use raw devices, just give the --size argument
> when creating your array, and it won't use the largest size possible.

	That's a great idea.  I think I'll implement it the next time I have
to re-organize one of the arrays.

> You'll want to work out how many KiB (i.e. 2^10 bytes) there are in a
> drive manufacturer's MB (10^6), GB (10^9) or TB (10^12) and use that as
> appropriate. For example, presumably all manufacturers' 500G drives will
> have at least 500*10^9 bytes of storage on them, and divided by 1024
> that's 488281250.

	I'm not confidant of that presumption.  I would not be surprised in
the least if some manufacturer produced a 1T drive with an actual 999.8G of
storage.  The device sizes on my arrays are all 1000.205G or 1500.300G,
respectively, so until I move to 3T drives, I'll just have to hope I don't
get a smaller one.

Re: Adding a smaller drive

[John Robinson]

On 28/06/2009 22:22, Leslie Rhorer wrote:
> 	I'm not confidant of that presumption.  I would not be surprised in
> the least if some manufacturer produced a 1T drive with an actual 999.8G

If they did that, they'd be lying in describing it as a 1TB drive. I 
wish they'd be more honest in the first place and sell them as 931GiB 
drives, or make real 1TiB drives, but the marketing literature does at 
least explain their definition of TB, GB etc.

Cheers,

John.

Re: Adding a smaller drive

[John Robinson]

On 28/06/2009 23:52, John Robinson wrote:
> On 28/06/2009 22:22, Leslie Rhorer wrote:
>>     I'm not confidant of that presumption.  I would not be surprised in
>> the least if some manufacturer produced a 1T drive with an actual 999.8G
> 
> If they did that, they'd be lying in describing it as a 1TB drive. I 
> wish they'd be more honest in the first place and sell them as 931GiB 
> drives, or make real 1TiB drives, but the marketing literature does at 
> least explain their definition of TB, GB etc.

Maybe it wouldn't be lying if they redefined 1KB to be 998 bytes. I 
vaguely recall there being an xkcd strip suggesting something similar...

Cheers,

John.

Re: Adding a smaller drive

[Goswin von Brederlow]

John Robinson <john.robinson@anonymous.org.uk> writes:

> On 28/06/2009 23:52, John Robinson wrote:
>> On 28/06/2009 22:22, Leslie Rhorer wrote:
>>>     I'm not confidant of that presumption.  I would not be surprised in
>>> the least if some manufacturer produced a 1T drive with an actual 999.8G
>>
>> If they did that, they'd be lying in describing it as a 1TB drive. I
>> wish they'd be more honest in the first place and sell them as
>> 931GiB drives, or make real 1TiB drives, but the marketing
>> literature does at least explain their definition of TB, GB etc.
>
> Maybe it wouldn't be lying if they redefined 1KB to be 998 bytes. I
> vaguely recall there being an xkcd strip suggesting something
> similar...
>
> Cheers,
>
> John.

At least on some drives they actually say
1.000.xxx.xxx kilo bytes.

MfG
        Goswin

RE: Adding a smaller drive

[Leslie Rhorer]

> On 28/06/2009 22:22, Leslie Rhorer wrote:
> > 	I'm not confidant of that presumption.  I would not be surprised in
> > the least if some manufacturer produced a 1T drive with an actual 999.8G
> 
> If they did that, they'd be lying in describing it as a 1TB drive. I

	'Not as long as they do publish the actual size.

> wish they'd be more honest in the first place and sell them as 931GiB
> drives, or make real 1TiB drives, but the marketing literature does at
> least explain their definition of TB, GB etc.

	Which illustrates the point, I think.  In any case, it won't be the
end of the world, but it does make just one more thing to nag me.

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Leslie" == Leslie Rhorer <lrhorer@satx.rr.com> writes:

Leslie> I may have to rethink my position on using raw drives.  If I
Leslie> partition the drives, I can make the partition a bit smaller
Leslie> than the whole drive, allowing for the addition of a future
Leslie> drive whose size is a bit off.  I hate to waste space, but being
Leslie> stuck with an undersized or limping array is worse.

This is not nearly as big a problem as it used to be.  Drive
manufacturers need to adhere to an IDEMA standard which requires them to
use a specific LBA count for each capacity class.

I.e. a 500GB Seagate drive must have exactly the same number of sectors
as a 500GB Western Digital or Hitachi.

The IDEMA LBA standard applies to 3.5" form factor drives over 160GB as
well as 2.5" FF drives over 80 GB.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Martin" == Martin K Petersen <martin.petersen@oracle.com> writes:

Martin> The IDEMA LBA standard applies to 3.5" form factor drives over
Martin> 160GB as well as 2.5" FF drives over 80 GB.

I should add that the above is for ATA drives.  For SCSI-class drives
the standard applies to 2.5" drives over 73GB and 3.5" drives over
450GB.

I did the maths for some common capacities:

Capacity (GB)	LBA count (512-byte blocks)
 250  		 488397168
 500  		 976773168
 750		1465149168
1000		1953525168
1500		2930277168
2000		3907029168

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Adding a smaller drive

[Mikael Abrahamsson]

On Sun, 28 Jun 2009, Martin K. Petersen wrote:

> This is not nearly as big a problem as it used to be.  Drive
> manufacturers need to adhere to an IDEMA standard which requires them to
> use a specific LBA count for each capacity class.

The 2TB WD GP drives have less sectors than their 2x their 1TB drives. The 
2TB ones adhere to the IDEMA standard (per your other email), but the 1TB 
ones do not.

(2TB ones have 3907029168 sectors, the 1TB ones have 1953103872).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:

Mikael> The 2TB WD GP drives have less sectors than their 2x their 1TB
Mikael> drives.

That's how it's supposed to be.


Mikael> The 2TB ones adhere to the IDEMA standard (per your other
Mikael> email), but the 1TB ones do not. (2TB ones have 3907029168
Mikael> sectors, the 1TB ones have 1953103872).

That, on the other hand, is pretty weird.  Call the capacity police!

I have two 500GB WDC GP drives in a machine in the lab and they report
the correct IDEMA size.  But other than that I don't have any WDC drives
that I check.

Which model is this?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Adding a smaller drive

[Mikael Abrahamsson]

On Sun, 28 Jun 2009, Martin K. Petersen wrote:

> Which model is this?

WD10EACS.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:

Mikael> On Sun, 28 Jun 2009, Martin K. Petersen wrote:
>> Which model is this?

Mikael> WD10EACS.

Weird.  The data sheet even lists the right (IDEMA) value:

http://www.wdc.com/en/products/productspecs.asp?driveid=336#jump24

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Adding a smaller drive

[Mikael Abrahamsson]

On Sun, 28 Jun 2009, Martin K. Petersen wrote:

>>>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:
>
> Mikael> On Sun, 28 Jun 2009, Martin K. Petersen wrote:
>>> Which model is this?
>
> Mikael> WD10EACS.
>
> Weird.  The data sheet even lists the right (IDEMA) value:
>
> http://www.wdc.com/en/products/productspecs.asp?driveid=336#jump24

Yeah, I just realised the value I quoted was what remained after 3ware 
superblock had been added (fdisk on single drive).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

RE: Adding a smaller drive

[Leslie Rhorer]

> >>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:
> 
> Mikael> The 2TB WD GP drives have less sectors than their 2x their 1TB
> Mikael> drives.
> 
> That's how it's supposed to be.

	You mean that's how IDEMA specs read.  Unless there is some legal
agreement signed by the drive manufacturer (or whomever) requiring adherence
to a certain spec, they can do just about anything they want.  Compliance
with a published spec is great, but unless some licensing agreement is in
place, it isn't enforceable.


> Mikael> The 2TB ones adhere to the IDEMA standard (per your other
> Mikael> email), but the 1TB ones do not. (2TB ones have 3907029168
> Mikael> sectors, the 1TB ones have 1953103872).
> 
> That, on the other hand, is pretty weird.  Call the capacity police!

	That's pretty much the point.  Not adhering to IDEMA specs is not
illegal.

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Leslie" == Leslie Rhorer <lrhorer@satx.rr.com> writes:

>> That's how it's supposed to be.

Leslie> You mean that's how IDEMA specs read.  Unless there is some
Leslie> legal agreement signed by the drive manufacturer (or whomever)
Leslie> requiring adherence to a certain spec, they can do just about
Leslie> anything they want.  Compliance with a published spec is great,
Leslie> but unless some licensing agreement is in place, it isn't
Leslie> enforceable.

Oracle is not a member so I'm not sure what (if any) leverage is
available as part of the IDEMA membership agreement.

I do think, however, that you are underestimating the power of industry
associations and standards bodies.  System manufacturers, enterprise
customers and governments absolutely refuse to buy things that are not
compliant.  So this is not about whether you can legally cut corners.
It is about being able to sell your product in the first place.

In this particular case IDEMA is an organization founded and run by the
drive manufacturers themselves.  They collaborated on the LBA spec and
have all publicly stated that they'll adhere to it.  It is not a
requirement that was forced upon them by an external entity.  Although
it was, of course, motivated by customers unhappy with the annoying
variation in LBA count between brands and even drive models...

-- 
Martin K. Petersen	Oracle Linux Engineering

RE: Adding a smaller drive

[Leslie Rhorer]

> >> That's how it's supposed to be.
> 
> Leslie> You mean that's how IDEMA specs read.  Unless there is some
> Leslie> legal agreement signed by the drive manufacturer (or whomever)
> Leslie> requiring adherence to a certain spec, they can do just about
> Leslie> anything they want.  Compliance with a published spec is great,
> Leslie> but unless some licensing agreement is in place, it isn't
> Leslie> enforceable.
> 
> Oracle is not a member so I'm not sure what (if any) leverage is
> available as part of the IDEMA membership agreement.
> 
> I do think, however, that you are underestimating the power of industry
> associations and standards bodies.  System manufacturers, enterprise
> customers and governments absolutely refuse to buy things that are not
> compliant.  So this is not about whether you can legally cut corners.
> It is about being able to sell your product in the first place.

	So a company like Apple could never compete with IBM?

	There are myriad examples of non-compliant software and hardware
being developed in a standards-based environment yet selling very well.  I
think maybe you are underestimating the vast buying power of individual
consumers and non-enterprise businesses.  The consumer sector has much
different requirements than industry, government, or the military.  If a
non-compliant product is less expensive than a compliant one, it will often
nonetheless sell very well in the private sector.  The number of people who
check for an IDEMA certification before grabbing a drive off the shelf at
Best Buy or Office Depot is zilch.

> In this particular case IDEMA is an organization founded and run by the
> drive manufacturers themselves.  They collaborated on the LBA spec and
> have all publicly stated that they'll adhere to it.  It is not a
> requirement that was forced upon them by an external entity.  Although
> it was, of course, motivated by customers unhappy with the annoying
> variation in LBA count between brands and even drive models...

	Well, first of all, in this very thread someone gave an example of a
modern drive which is apparently non-compliant.  If it is true, then your
argument is clearly less than convincing.  Even if not, however, voluntary
adherence to a set of standards is just that: voluntary.  If a manufacturer
feels it is economically prudent to violate such standards, there is nothing
stopping them, and if adhering to a standard in any particular instance
costs the company more money than producing a non-standard product, there's
a good chance they may decide to violate the standard.

	I'm not arguing against standards, here.  I'm just saying there's a
good chance of encountering non-compliant items in any consumer oriented
industry.

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Leslie" == Leslie Rhorer <lrhorer@satx.rr.com> writes:

>> I do think, however, that you are underestimating the power of
>> industry associations and standards bodies.  System manufacturers,
>> enterprise customers and governments absolutely refuse to buy things
>> that are not compliant.  So this is not about whether you can legally
>> cut corners.  It is about being able to sell your product in the
>> first place.

Leslie> 	So a company like Apple could never compete with IBM?

Who says that Apple doesn't care about the LBA count?  Most desktop
system vendors use disk imaging to perform burn-in and software preload.
It matters to them.  Same goes for OS deployment on the business desktop
end of things.

I don't have any idea whether more desktop class drives are sold
individually as opposed to as part of a new computer.  But that doesn't
really matter.  Because fact is that it's the system vendors that set
the bar for standards compliance.

I am not sure what the incentive would be for the drive vendors to
provide different capacities/firmware loads for drives sold directly to
consumers.  Until the IDEMA LBA spec was ratified we were talking about
capacity variations of a few percent within a given class.  I don't
think consumers care about that nearly as much as we computer
professionals do.


Leslie> There are myriad examples of non-compliant software and hardware
Leslie> being developed in a standards-based environment yet selling
Leslie> very well.  I think maybe you are underestimating the vast
Leslie> buying power of individual consumers and non-enterprise
Leslie> businesses.  

I don't disagree that there's a lot of crap hardware out there.
Absolutely.  And a sizable portion of said crap is in the USB-ATA bridge
designed-by-dyslexic-monkeys category.

However, there's only a handful of disk drive manufacturers.  And they
are all pretty good at adhering to existing standards for the reasons I
outlined earlier.  Namely that they have to sell exactly the same drives
to customers with higher standards than aforementioned dyslexic monkeys.

Here's the LBA count for a bunch of currently shipping 3.5" 1TB drives
that I was able to find the data sheets for within a couple of minutes
of googling:

DRIVE				LBA COUNT
---------------------------------------------
Hitachi Deskstar 7K1000:	1,953,525,168
Hitachi Deskstar 7K1000.B:	1,953,525,168
Seagate Barracuda ES.2:		1,953,525,168
Seagate Barracuda 7200.11:	1,953,525,168
Seagate Barracuda 7200.12:	1,953,525,168
Seagate Barracuda LP:		1,953,525,168
Samsung SpinPoint F1 DT:        1,953,525,168
Samsung Ecogreen F2:		1,953,525,168
WDC Caviar Black:		1,953,525,168
WDC Caviar Green:		1,953,525,168
WDC Caviar RE3:			1,953,525,168
WDC Caviar RE2-GP:		1,953,525,168
---------------------------------------------


Leslie> Well, first of all, in this very thread someone gave an example
Leslie> of a modern drive which is apparently non-compliant. 

That turned out to be a drive sitting behind a RAID controller which
reserves a portion of the drive for its own use.

-- 
Martin K. Petersen	Oracle Linux Engineering

RE: Adding a smaller drive

[Leslie Rhorer]

> -----Original Message-----
> From: Martin K. Petersen [mailto:martin.petersen@oracle.com]
> Sent: Sunday, July 05, 2009 7:06 PM
> To: lrhorer@satx.rr.com
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Adding a smaller drive
> 
> >>>>> "Leslie" == Leslie Rhorer <lrhorer@satx.rr.com> writes:
> 
> >> I do think, however, that you are underestimating the power of
> >> industry associations and standards bodies.  System manufacturers,
> >> enterprise customers and governments absolutely refuse to buy things
> >> that are not compliant.  So this is not about whether you can legally
> >> cut corners.  It is about being able to sell your product in the
> >> first place.
> 
> Leslie> 	So a company like Apple could never compete with IBM?
> 
> Who says that Apple doesn't care about the LBA count?  Most desktop

	I'm afraid you missed my point entirely.  In the 1980s and early
1990s, Apple was strictly proprietary, and few businesses, governmental
agencies, or military applications would purchase Apple machines.  Yet it
sold well in the consumer sector.  Despite not being based upon an open
standard, Apple was able to compete.

> system vendors use disk imaging to perform burn-in and software preload.
> It matters to them.  Same goes for OS deployment on the business desktop
> end of things.
> 
> I don't have any idea whether more desktop class drives are sold
> individually as opposed to as part of a new computer.  But that doesn't
> really matter.  Because fact is that it's the system vendors that set
> the bar for standards compliance.

	And consumers ignore it.  For the most part, they could not care
less.

> I am not sure what the incentive would be for the drive vendors to
> provide different capacities/firmware loads for drives sold directly to
> consumers.

	By sealing his oil barrels with 39 drops of solder, rather than 40,
John D. Rockefeller saves some $50,000 a year.  Take a few pennies, multiply
by 100 million or so consumers, and you wind up with a million bucks.  I
don't know that they can save a few cents by skimping on the number of
sectors, but if someone can, it is a powerful incentive to ignore the spec
for consumer class drives.

> Until the IDEMA LBA spec was ratified we were talking about
> capacity variations of a few percent within a given class.  I don't
> think consumers care about that nearly as much as we computer
> professionals do.

	Which is my point, and since the systems to which I refer are owned
by me personally, rather than by my company, I have a similar perspective in
this case.

> However, there's only a handful of disk drive manufacturers.  And they
> are all pretty good at adhering to existing standards for the reasons I
> outlined earlier.  Namely that they have to sell exactly the same drives
> to customers with higher standards than aforementioned dyslexic monkeys.

	I don't doubt it for a second.  To be sure, I'm not saying it will
happen, or even that it is highly likely, just that it is possible, and with
my luck, it would be the 1 out of 100 that winds up in my hands.

> Leslie> Well, first of all, in this very thread someone gave an example
> Leslie> of a modern drive which is apparently non-compliant.
> 
> That turned out to be a drive sitting behind a RAID controller which
> reserves a portion of the drive for its own use.

	That's reassuring.

Re: Adding a smaller drive

[John Robinson]

On 28/06/2009 23:33, Mikael Abrahamsson wrote:
> (2TB ones have 3907029168 sectors, the 1TB ones have 1953103872).

Those 1TB ones are under 1TB: they have 999989182464 bytes.

Cheers,

John.

Re: Adding a smaller drive

[Mikael Abrahamsson]

On Mon, 29 Jun 2009, John Robinson wrote:

> On 28/06/2009 23:33, Mikael Abrahamsson wrote:
>> (2TB ones have 3907029168 sectors, the 1TB ones have 1953103872).
>
> Those 1TB ones are under 1TB: they have 999989182464 bytes.

If I use smartctl instead of using fdisk after 3ware superblock, it says:

Device Model:     WDC WD10EACS-00ZJB0
User Capacity:    1,000,204,886,016 bytes

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: Adding a smaller drive

[Goswin von Brederlow]

"Martin K. Petersen" <martin.petersen@oracle.com> writes:

>>>>>> "Leslie" == Leslie Rhorer <lrhorer@satx.rr.com> writes:
>
> Leslie> I may have to rethink my position on using raw drives.  If I
> Leslie> partition the drives, I can make the partition a bit smaller
> Leslie> than the whole drive, allowing for the addition of a future
> Leslie> drive whose size is a bit off.  I hate to waste space, but being
> Leslie> stuck with an undersized or limping array is worse.
>
> This is not nearly as big a problem as it used to be.  Drive
> manufacturers need to adhere to an IDEMA standard which requires them to
> use a specific LBA count for each capacity class.
>
> I.e. a 500GB Seagate drive must have exactly the same number of sectors
> as a 500GB Western Digital or Hitachi.
>
> The IDEMA LBA standard applies to 3.5" form factor drives over 160GB as
> well as 2.5" FF drives over 80 GB.

Is that realy exactly so many LBA sectors or at least as many?

I don't really see anything wrong with a 500G drive having a few more
sectors. And I know my Maxtor 200G disk is 3G bigger than Seagates.

MfG
        Goswin

Re: Adding a smaller drive

[Martin K. Petersen]

>>>>> "Goswin" == Goswin von Brederlow <goswin-v-b@web.de> writes:

>> The IDEMA LBA standard applies to 3.5" form factor drives over 160GB
>> as well as 2.5" FF drives over 80 GB.

Goswin> Is that realy exactly so many LBA sectors or at least as many?

Exactly that number.  IDEMA provides a precise formula for converting
marketing gigabytes to 512-byte (and 4KB) blocks.


Goswin> I don't really see anything wrong with a 500G drive having a few
Goswin> more sectors.

I do.  The whole purpose of the spec is to ensure that you can swap
drives in a RAID setup without having to find an exact replacement.  If
your array has drives with "extra" blocks then it becomes impossible to
swap in a drive that adheres to the IDEMA spec.


Goswin> And I know my Maxtor 200G disk is 3G bigger than Seagates.

200GB is old enough that the spec doesn't apply.  I know that
technically it says 160GB and above.  But in reality it took a while for
vendors to start adhering.  And the 200GB capacity point predates 160GB.

The usual rule of thumb is that 320GB vintage drives and above get it
right.  And any new drive, regardless of capacity.

-- 
Martin K. Petersen	Oracle Linux Engineering

RE: Adding a smaller drive

[Leslie Rhorer]

> > Leslie> I may have to rethink my position on using raw drives.  If I
> > Leslie> partition the drives, I can make the partition a bit smaller
> > Leslie> than the whole drive, allowing for the addition of a future
> > Leslie> drive whose size is a bit off.  I hate to waste space, but being
> > Leslie> stuck with an undersized or limping array is worse.
> >
> > This is not nearly as big a problem as it used to be.  Drive
> > manufacturers need to adhere to an IDEMA standard which requires them to
> > use a specific LBA count for each capacity class.
> >
> > I.e. a 500GB Seagate drive must have exactly the same number of sectors
> > as a 500GB Western Digital or Hitachi.
> >
> > The IDEMA LBA standard applies to 3.5" form factor drives over 160GB as
> > well as 2.5" FF drives over 80 GB.
> 
> Is that realy exactly so many LBA sectors or at least as many?
> 
> I don't really see anything wrong with a 500G drive having a few more
> sectors. And I know my Maxtor 200G disk is 3G bigger than Seagates.

	'Excellent point.  If the spec calls for a minimum of sectors, then
it is quite possible a complaint drive might well have fewer sectors than
the ones I used to build the array.  OTOH, all of the 1T drives on my
systems  have precisely the same number of user available sectors, and all
the 1.5T drives have the same number.  Since the drives represent not only
different models from one manufacturer but also different manufacturers,
this suggests to me an adherence to a specific spec.  On yet the other hand,
it may merely mean they all have the same number of platters and similar
architectures.  The 1.5T drives are less than 1.5 times bigger than the 1T
drives, so I could not replace a 3 drive 1T triplet with a pair of 1.5T
drives.

Re: Adding a smaller drive

[Billy Crook]

My WDC WD20EADS-00R6B0 drives have 3907029168 512byte sectors for a
total of 2000398934016 bytes.  I don't buy replacement drives for raid
arrays unless 1) they are the same model or 2) I check the sector
count.  It's not a big deal to do.  The first google result for "2tb
drive" has a picture of the label that clearly shows the number of
sectors.  I'd rather do one comparison between exact numbers than look
for vague numbers and fine print compliance to some standard few if
any people have ever heard of.

Re: Adding a smaller drive

[Bill Davidsen]

Leslie Rhorer wrote:
>>> Leslie> I may have to rethink my position on using raw drives.  If I
>>> Leslie> partition the drives, I can make the partition a bit smaller
>>> Leslie> than the whole drive, allowing for the addition of a future
>>> Leslie> drive whose size is a bit off.  I hate to waste space, but being
>>> Leslie> stuck with an undersized or limping array is worse.
>>>
>>> This is not nearly as big a problem as it used to be.  Drive
>>> manufacturers need to adhere to an IDEMA standard which requires them to
>>> use a specific LBA count for each capacity class.
>>>
>>> I.e. a 500GB Seagate drive must have exactly the same number of sectors
>>> as a 500GB Western Digital or Hitachi.
>>>
>>> The IDEMA LBA standard applies to 3.5" form factor drives over 160GB as
>>> well as 2.5" FF drives over 80 GB.
>>>       
>> Is that realy exactly so many LBA sectors or at least as many?
>>
>> I don't really see anything wrong with a 500G drive having a few more
>> sectors. And I know my Maxtor 200G disk is 3G bigger than Seagates.
>>     
>
> 	'Excellent point.  If the spec calls for a minimum of sectors, then
> it is quite possible a complaint drive might well have fewer sectors than
> the ones I used to build the array.  OTOH, all of the 1T drives on my
> systems  have precisely the same number of user available sectors, and all
> the 1.5T drives have the same number.  Since the drives represent not only
> different models from one manufacturer but also different manufacturers,
> this suggests to me an adherence to a specific spec.  On yet the other hand,
> it may merely mean they all have the same number of platters and similar
> architectures.  The 1.5T drives are less than 1.5 times bigger than the 1T
> drives, so I could not replace a 3 drive 1T triplet with a pair of 1.5T
> drives.
>   

That last sentence is important! If this is a standard, then it would 
seem to be actually intended to deceive the consumer. If there is to be 
a standard for 1, 1.5, and 2, they really should have some sensible 
relationship in size.

That said, I confess that I use partitions and leave a little breathing 
room on my drives when building a raid array.

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

Re: Adding a smaller drive

[John Robinson]

On 04/07/2009 15:59, Bill Davidsen wrote:
> Leslie Rhorer wrote:
>>  The 1.5T drives are less than 1.5 times bigger than the 1T
>> drives, so I could not replace a 3 drive 1T triplet with a pair of 1.5T
>> drives.
> 
> That last sentence is important! If this is a standard, then it would 
> seem to be actually intended to deceive the consumer. If there is to be 
> a standard for 1, 1.5, and 2, they really should have some sensible 
> relationship in size.
> 
> That said, I confess that I use partitions and leave a little breathing 
> room on my drives when building a raid array.

I think I might take to doing that too, making my partitions/arrays 
multiples of 1,000,000,000 bytes (a drive maker's 1GB) where possible, 
just to be sure :-)

Cheers,

John.

RE: Adding a smaller drive

[Leslie Rhorer]

> > That last sentence is important! If this is a standard, then it would
> > seem to be actually intended to deceive the consumer. If there is to be
> > a standard for 1, 1.5, and 2, they really should have some sensible
> > relationship in size.
> >
> > That said, I confess that I use partitions and leave a little breathing
> > room on my drives when building a raid array.
> 
> I think I might take to doing that too, making my partitions/arrays
> multiples of 1,000,000,000 bytes (a drive maker's 1GB) where possible,
> just to be sure :-)

	Well, that's not quite possible, of course, since sectors are
usually 512 bytes, and 1E9 is not a multiple of 512.  Indeed, that's where
this whole situation is ridiculous. For drive manufacturers to even consider
using GB as a measuring basis is ludicrous.  If sectors were 1000 bytes, and
if computer registers were base 10, it would be an entirely different
matter, but the fact is the sector size is 2^9 and all the register
boundaries are going to be multiples of 2, not 10.

Re: Adding a smaller drive

[John Robinson]

On 05/07/2009 23:03, Leslie Rhorer wrote:
[...]
>> I think I might take to doing that too, making my partitions/arrays
>> multiples of 1,000,000,000 bytes (a drive maker's 1GB) where possible,
>> just to be sure :-)
> 
> 	Well, that's not quite possible, of course, since sectors are
> usually 512 bytes, and 1E9 is not a multiple of 512.  Indeed, that's where
> this whole situation is ridiculous. For drive manufacturers to even consider
> using GB as a measuring basis is ludicrous.  If sectors were 1000 bytes, and
> if computer registers were base 10, it would be an entirely different
> matter, but the fact is the sector size is 2^9 and all the register
> boundaries are going to be multiples of 2, not 10.

But 10^9 is divisible by 512: 10^9 = (2*5)^9 = 2^9 * 5^9. There are 
therefore 1953125 512-byte sectors in 1 drive maker's GB.

Cheers,

John.

RE: Adding a smaller drive

[Leslie Rhorer]

> >> I think I might take to doing that too, making my partitions/arrays
> >> multiples of 1,000,000,000 bytes (a drive maker's 1GB) where possible,
> >> just to be sure :-)
> >
> > 	Well, that's not quite possible, of course, since sectors are
> > usually 512 bytes, and 1E9 is not a multiple of 512.  Indeed, that's
> where
> > this whole situation is ridiculous. For drive manufacturers to even
> consider
> > using GB as a measuring basis is ludicrous.  If sectors were 1000 bytes,
> and
> > if computer registers were base 10, it would be an entirely different
> > matter, but the fact is the sector size is 2^9 and all the register
> > boundaries are going to be multiples of 2, not 10.
> 
> But 10^9 is divisible by 512: 10^9 = (2*5)^9 = 2^9 * 5^9. There are
> therefore 1953125 512-byte sectors in 1 drive maker's GB.

	Oh, good heavens!  Silly me, how could I have missed that?

Re: Adding a smaller drive

[Bill Davidsen]

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.

Re: Adding a smaller drive

[Greg Freemyer]

On Tue, Jun 30, 2009 at 1:01 PM, Bill Davidsen<davidsen@tmr.com> wrote:
> Leslie Rhorer wrote:
>>>>
<snip>
>>        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.

Any recent version of hdparm can get/set HPA for LBA-48 drives.  That
feature went in a couple years ago. And it is the only tool I know
that works with LBA-48 drives.  (ie. drives larger than 128 GiB).

If your version is too old you can get a new version off of
sourceforge I believe.

Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
http://www.norcrossgroup.com/forms/whitepapers/Forensic%20Processing%20of%20Exchange%20WP%20final.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding a smaller drive

[Bill Davidsen]

Greg Freemyer wrote:
> On Tue, Jun 30, 2009 at 1:01 PM, Bill Davidsen<davidsen@tmr.com> wrote:
>   
>> Leslie Rhorer wrote:
>>     
> <snip>
>   
>>>        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.
>>     
>
> Any recent version of hdparm can get/set HPA for LBA-48 drives.  That
> feature went in a couple years ago. And it is the only tool I know
> that works with LBA-48 drives.  (ie. drives larger than 128 GiB).
>
> If your version is too old you can get a new version off of
> sourceforge I believe.
>   

I was actually thinking of a GUI tool, used for partition management, 
but I can't recall the name (I do most things like that from the cli). 
There's also SleuthKit, which may handle larger drives, 1TB limit comes 
to mind, but I was using it for something else rather than HPA.

In any case, some drives seem to use that for sizing, just wanted to 
note that to the O.P.

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