SCIENTIFIC-LINUX-USERS Archives

March 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Wed, 30 Mar 2016 23:43:37 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
On 03/29/2016 06:06 PM, Thomas Leavitt wrote:
>
> This is a system I inherited…
>
> I looked, and there are several drives of this type already in the 
> array. Including ones I have not replaced. However, they show a 
> separate pattern…
>
> ...
>
>  I’m thinking that the WD1002FBYS-0 is actually, natively, one sector 
> larger than its descendant, the WD1003FBYX-0, and that shoving an 
> invalid partition table onto it won’t matter… except when the system 
> attempts to write to that last sector. At which point, I have no idea 
> what is going to happen.
>
> Thoughts? What am I missing here? I seriously miss the simplicity of 
> swapping a replacement drive into a hardware raid array. Ugh.
>
> ...
>
> Disk /dev/sdh: 1000.2 GB, 1000204886016 bytes
>
> 81 heads, 63 sectors/track, 382818 cylinders
>
> Units = cylinders of 5103 * 512 = 2612736 bytes
>
> ...
>
> Disk /dev/sdk: 1000.2 GB, 1000204886016 bytes
>
> 255 heads, 63 sectors/track, 121601 cylinders
>
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
>
Thomas, the WD1002FBYS-0 and the WD1003FBYX-0 have the same number of 
user accessible sectors, 1,953,525,168 per the spec sheets (see: 
http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701338.pdf and 
http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701281.pdf ; in 
both cases the specs, including LBA, are found on page 2).

However, the drives' translated geometries don't match, which results in 
the following math (using your drive devices above):
sdh: 2612736*382818=1000202370048 bytes
sdk: 8225280*121601=1000202273280 bytes

This is a difference of 96768 bytes, or 189 sectors in favor of sdh; and 
the linux MDRAID rightly complains.  Note that neither geometry wrings 
the full 1000204886016 bytes; for that you need a geometry of C=646007 , 
H=48, S=63 (or just use LBA to begin with; incidentally, the number of 
cylinders, 646007, is only divisible by 547 and 1181 and neither are 
usable for either the number of heads or the number of sectors per 
track).  By that metric, sdh is short 2515968 byte (4914 sectors) and 
sdk is short 2612736 bytes (5103 sectors) which coincidentally enough is 
the unit size for sdh.......

Geometry issues, especially with older fdisk/older kernel are rather 
common; the good news is that sfdisk can force the geometry; see 
https://www.dark.ca/2009/06/22/force-disk-geometry-with-sfdisk/ for an 
example.  Better is to use native LBA for 'partitioning' with the '-u' 
switch to fdisk, which is the default in EL7.

It is just wrong and strange that thirty years after the introduction of 
LBA22 for IDE drives (1986 by Western Digital; LBA28 in 1994 and LBA48 
in 2003) we still have to chase our tails over CHS geometry (which in 
zoned-bit-recording drives is a meaningless concept in the first place).

ATOM RSS1 RSS2