SSD Posted February 9, 2011 Share Posted February 9, 2011 What is the most reliable way to automatedly determine if there is an HPA on a drive. I am thinking to add an attribute to MyMain so that users can clearly see that their disk has an HPA before moving to 5.0. Looking for something that is the most reliable across drives and controllers. Thinking of just looking at the disk size information, but there might be a better way. Thanks! Quote Link to comment
Joe L. Posted February 9, 2011 Share Posted February 9, 2011 What is the most reliable way to automatedly determine if there is an HPA on a drive. I am thinking to add an attribute to MyMain so that users can clearly see that their disk has an HPA before moving to 5.0. Looking for something that is the most reliable across drives and controllers. Thinking of just looking at the disk size information, but there might be a better way. Thanks! hdparm -N gives the accessible and native sizes. The first has always been correct, the second un-reliable on many disks as reported incorrectly by the kernel. Joe L. Quote Link to comment
BRiT Posted February 9, 2011 Share Posted February 9, 2011 I'm not sure if this is the typical output on a base unRAID install, but on a Slackware Current install the output indicates if HPA is enabled or disabled. There's a slight version difference between unRAID 5.0b4 and Slackware Current (9.37 vs 9.27), but the output looks similar. #hdparm -V hdparm v9.37 # hdparm -N /dev/sda /dev/sda: max sectors = 312581808/312581808, HPA is disabled #hdparm -N /dev/sdg /dev/sdg: max sectors = 3907029168/3907029168, HPA is disabled #/cache/.root/unraid/50b4/usr/sbin/hdparm -V hdparm v9.27 #/cache/.root/unraid/50b4/usr/sbin/hdparm -N /dev/sda /dev/sda: max sectors = 312581808/312581808, HPA is disabled #/cache/.root/unraid/50b4/usr/sbin/hdparm -N /dev/sdg /dev/sdg: max sectors = 3907029168/3907029168, HPA is disabled Quote Link to comment
bubbaQ Posted February 9, 2011 Share Posted February 9, 2011 Unfortunately, the second number reported by some drives for the native max sectors is bogus. Quote Link to comment
SSD Posted February 10, 2011 Author Share Posted February 10, 2011 Is the first number returned by hdparm -N the current sector count. So if a 2T had an HPA, the first number would be something other than (less than) 3907029168? True? Quote Link to comment
bubbaQ Posted February 10, 2011 Share Posted February 10, 2011 The only way to REALLY know is to compare what the drive returns, to the label on the drive, and you can also check the MFG's website to make double sure. Here is what I get for one drive: /dev/sda: max sectors = 18446744073321613488/3907029168(18446744073321613488?), HPA setting seems invalid Model=WDC WD20EARS-00S8B1 , FwRev=80.00A80 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16? CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744073321613488 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7 /dev/sda: ATA device, with non-removable media Model Number: WDC WD20EARS-00S8B1 Firmware Revision: 80.00A80 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5 Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Quote Link to comment
BRiT Posted February 10, 2011 Share Posted February 10, 2011 bubbaQ, which version of hdparm (hdparm -V) was that from? Quote Link to comment
bubbaQ Posted February 10, 2011 Share Posted February 10, 2011 which version of hdparm (hdparm -V) was that from? 9.3 Quote Link to comment
bubbaQ Posted February 10, 2011 Share Posted February 10, 2011 FWIW, 9.27 does better. /dev/sda: max sectors = 3907029168/3907029168, HPA is disabled root@aa:~/hdparm-9.27# ./hdparm -N -i -I /dev/sda /dev/sda: Model=WDC WD20EARS-00S8B1, FwRev=80.00A80 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=3907029168 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7 * signifies the current active mode ATA device, with non-removable media Model Number: WDC WD20EARS-00S8B1 Firmware Revision: 80.00A80 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6 Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Quote Link to comment
BRiT Posted February 10, 2011 Share Posted February 10, 2011 Hrm, that version is quite old 9.3 [2008-11-04], but likely what was included in previous unRAID distros. It seems unRAID 4.7 and 5.0b4 both use version 9.27 [2009-10-02]. Slackware Current has available 9.37 [2011-01-24]. It's good to see a more current version fairs better. Quote Link to comment
SSD Posted February 10, 2011 Author Share Posted February 10, 2011 Ok, since HDPARM does not look like a reliable method, I am going for somethiing more brute force and less elegant - drive sizes. HERE IS AN EXAMPLE (click link and then click on screen shot) of someone with HPA that can be detected by looking at the drive sizes. unRAID reports the size of each drive. There are no that many discreet sizes: 244,198,552 - 250G 488,386,552 - 500G 732,574,552 - 750G 976,762,552 - 1T 1,465,138,552 - 1.5T 1,953,514,552 - 2T So it appears any size ending in 552 is valid and does not contain an HPA. This can't be an accident. I also found these valid sizes, I suppose from before drive sizes were standardized. 245,117,344 Maxtor 250G 293,057,320 Maxtor 300G 293,036,152 Seagate 300G 390,771,352 Seagate 400G 625,131,832 WD 640G I will special case these sizes as not containing HPA. So if it doesn't end in 552 and it isn't one of these, I will indicate that it contains an HPA (or at least appears to contain an HPA). If anyone has any valid sizes that differ from these (that don't have an HPA), please post them. I believe that these sizes will cover 98%+ of drives in people's arrays. Hopefully drive manufacturers will stick with the 552 last 3 digits going forward and this will be a reliable method without having to update on every new drive size release. I guess we'll see when the 3T come out! Seem reasonable? Quote Link to comment
BRiT Posted February 10, 2011 Share Posted February 10, 2011 I just examined my XBMC front end to see what it's 20GB laptop drive reports and it has HPA enabled on it [current 39070080, native 39179952]. WD1600 BEVS 160GB: 312,581,808 Quote Link to comment
RobJ Posted February 10, 2011 Share Posted February 10, 2011 Seagate 320GB : ST3320620AS size: 312571192 (no HPA) All my other drives agree with your table. I suspect you may be able to get away with just checking the last 2 digits for '52', but you may want more data points before deciding that. Of 'modern' drives, only the 640GB drives don't really fit the test. That Maxtor 250G is especially non-standard. When I get a chance, I'll check many of the other drives I have records for. The relation between sector count and unRAID drive size is: drive_size = ( sector_count - 64 ) / 2 or conversely: sector_count = ( drive_size * 2 ) + 64 Which is why so many of the modern drives (size ending in 552) have sector counts ending in 168. The true test of the HPA though is to use a recent version of hdparm and compare current with native sector counts. The Gigabyte HPA is ALWAYS (so far!) associated with a difference of 2113 sectors. (That being an odd number relates to what Tom was referring to.) So a sector count ending in 168 minus 113 results in the HPA sector count ending in 055. 2113 sectors equals 1056.5KB, or 1056KB plus one sector. If you subtract 1056 from the normal drive size ending in 552, and ignore that one sector, you get the HPA size ending in 496 (552 - 056), and that is how it has been calculated prior to v4.7. How did Tom get away with ignoring that sector? Because up until v4.7, the unRAID partition started on sector 63 instead of 64, even though 64 sectors had been reserved in the calculations above. So there was always an extra and unused sector at the end of the drive. But now if the partition starts on sector 64, that unused sector is no longer available, and therefore a Gigabyte HPA conflicts with the last sector of the unRAID partition. Which is why he had to calculate the size slightly smaller, but then it no longer matched the previously configured size. If my logic here is wrong, please feel free to gently correct me. One suggestion to deal with it, if drive is 4K-aligned (starts at 64), require HPA removal; otherwise just accept it as it is (with the previous disk size, since it was correct) and flag it internally (disk.cfg & super.dat?), and not report is as a wrong size. Quote Link to comment
SSD Posted February 11, 2011 Author Share Posted February 11, 2011 Ok - so unRAID will tell me the sizes of the disks in the array. But how can I get the same size using a conventional Linux command? unMain is currently getting the disk size, but it is not exactly the same as what unRAID reports. I need a command (or series of commands) that will result in unRaid's number for disks not already in the array. Help! Thanks! Quote Link to comment
RobJ Posted February 16, 2011 Share Posted February 16, 2011 When I get a chance, I'll check many of the other drives I have records for There were a number of other things I should have been working on, but this is what I started today, so here it is. Probably not the best use of my time, but hopefully it is of some use at least. This is a table of drives used by unRAID users, to possibly help with understanding drive sizes and sector counts and HPA detection. A lot of it is redundant, but may help you understand what is important and what is not. It is still weak on the smaller and older drives, but I got tired of the whole thing. There are a few surprises in there, surprising at least to me. --Drive Model--------Size--------Sectors- 40GB Maxtor_6E040L0 80293248 74GB WDC_WD740GD 145226112 80GB ST380011A 156301488 ST3808110AS 78150712 156301488 ST380815AS 156301488 WDC_WD800BB 78150712 156301488 120GB SAMSUNG_SP1213C 117246496 234493056 WDC_WD1200JB 117220792 234441648 WDC_WD1200JB 117187528 234375000->234375120 (v4.5) (capacity increase by kernel!?!) 160GB Maxtor_6Y160P0 320173056 MAXTOR_STM3160815AS 312581808 SAMSUNG HD161HJ 156290872 312581808 ST3160827AS 312581808 ST3160812AS 156290872 312581808 WDC_WD1600BEVS 312581808 200GB Maxtor 6B200P0 199148512 398297088 Maxtor_6L200S0 398297088 Maxtor_6Y200P0 199148512 398297088 ST3200822A 195360952 390721968 WDC_WD2000JB 390721968 250GB Hitachi_HDS722525 244198552 488397168 Maxtor_6B250R0 245117344 490234752 Maxtor_6V250F0 490234752 Maxtor_6Y250P0 245117344 490234752 SAMSUNG_HA250JC 488397168 SAMSUNG_SP2504C 244198552 488397168 SAMSUNG_SP2514N 488397168 ST3250823AS 244198552 488397168 ST3250620A 244198552 488397168 WDC_WD2500BB 488397168 WDC_WD2500JD 244198552 488397168 WDC_WD2500JS 244198552 488397168 WDC_WD2500KS 244198552 488397168 300GB Maxtor_6B300S0 293057320 586114704 Maxtor_6L300R0 293057320 586114704 Maxtor_6V300F0 293057320 586114704 ST3300622A 293036152 586072368 ST3300631A 293036152 586072368 ST3300831A 293036152 586072368 320GB Hitachi HDT72503 312571192 625142448 MAXTOR_STM3320620A 312571192 625142448 ST3320620AS 312567380 625134827 (?!?no HPA reported!) ST3320620AS 312571192 625142448 ST9320423AS 312571192 625142448 WDC_WD3200JB 312571192 625142448 WDC_WD3200JS 625142448 400GB Hitachi_HDS724040 390711352 781422768 SAMSUNG_HD403LJ 390711352 781422768 ST3400620A 390711352 781422768 ST3400833A 390711352 781422768 WDC_WD4000AAKS 390711352 781422768 WDC_WD4000KD 390711352 781422768 500GB Hitachi_HDT72505 488386552 976773168 MAXTOR_STM3500630A 488386552 976773168 SAMSUNG_HD501LJ 488386552 976773168 SAMSUNG_HD502HI 976773168 ST3500320AS 488386552 976773168 ST3500410AS 488386552 976773168 ST3500630AS 488386552 976773168 ST3500630NS 488386552 976773168 ST3500641AS 488386552 976773168 ST3500830A 488386552 976773168 WDC_WD5000AAKS 488386552 976773168 WDC_WD5001ABYS 488386552 976773168 640GB WDC_WD6401AALS 625131832 1250263728 WDC_WD6400AAKS 625131832 1250263728 750GB GB0750C4414? 1465149168 Hitachi_HDS72107 732574552 1465149168 Hitachi_HDT72107 732574552 1465149168 SAMSUNG_HD753LJ 732574552 1465149168 ST3750640AS 732574552 1465149168 ST3750330AS 732574552 1465149168 WDC_WD7500AADS 732574552 1465149168 WDC_WD7500AAKS 732574552 1465149168 WDC_WD7500AYYS 732574552 1465149168 1TB Hitachi_HDS72101 976762552 1953525168 MAXTOR_STM31000340AS 976762552 1953525168 SAMSUNG_HD103SJ 976762552 1953525168 ST31000333AS 976762552 1953525168 ST31000340AS 976762552 1953525168 ST31000340NS 976762552 1953525168 ST31000528AS 976762552 1953525168 WDC_WD10EACS 976762552 1953525168 WDC_WD10EADS 976762552 1953525168 WDC_WD10EARS 976762552 1953525168 WDC_WD10EAVS 976762552 1953525168 WDC_WD1000FYPS 976762552 1953525168 WDC_WD1001FALS 976762552 1953525168 1.5TB SAMSUNG_HD154UI 1465138552 2930277168 ST31500341AS 1465138552 2930277168 ST31500541AS 1465138552 2930277168 WDC_WD15EADS 1465138552 2930277168 WDC_WD15EARS 1465138552 2930277168 2TB Hitachi_HDS72202 1953514552 3907029168 Hitachi_HDS72302 1953514552 3907029168 SAMSUNG_HD203WI 1953514552 3907029168 SAMSUNG_HD204UI 1953514552 3907029168 ST32000542AS 1953514552 3907029168 WDC_WD20EADS 1953514552 3907029168 WDC_WD20EARS 1953514552 3907029168 WDC_WD20EVDS 1953514552 3907029168 WDC_WD2001FASS 1953514552 3907029168 WDC_WD2002FYPS 1953514552 3907029168 --HPA Drive----------Size--------Sectors- ST380811AS 156299375 (native=156301488) (v4.4.2) WDC_WD1200JB 117220792* 234439535->234441648 (v4.5-beta6) (*HPA disabled by kernel! Bad!) Maxtor_6Y160P0 160085440 320170943 (native=320173056) (v4.5) Maxtor_6L300S0 586112591 (native=586114704) (v4.7) Maxtor_6L300R0 293057320* 586112591 (native=586114704) (v4.4.2) (*HPA disabled by kernel! Bad!) ST3300831AS 293035096 586070255 (native=586072368) (v4.5.1) ST3320620AS 312570132 625140335 (native=625142448) (v4.7) ST3500320AS 976771055 (!no HPA reported!) (v4.7) ST3500630NS 488385496 976771055 (native=976773168) (v4.5-beta8) WDC_WD5000KS 488385496 976771055 (native=976773168) (v4.5-beta8) Hitachi_HDS72101 976761496 1953523055 (native=1953525168) (v4.5) Hitachi_HDS72101 976761492 1953523055 (native=1953525168) (v4.7) SAMSUNG HD103UJ 976761496 1953523055 (native=1953525168) (v4.5-beta11) ST31000340AS 976761496 1953523055 (native=1953525168) (v4.5) ST31000340AS 976761492 1953523055 (native=1953525168) (v5.0-beta3) WDC_WD10EADS 976761496 1953523055 (native=1953525168) (v4.6) SAMSUNG_HD154UI 1465137496 2930275055 (native=2930277168) (v4.5-beta7) ST31500341AS 1465137496 2930275055 (native=2930277168) (v4.5-beta7) ST31500341AS 1465137492 2930275055 (native=2930277168) (v5.0-beta3) WDC_WD15EADS 1465137496 2930275055 (native=2930277168) (v4.6) ST32000542AS 3907027055 (native=3907029168) (v4.7) WDC_WD20EADS 1953513496 3907027055 (native=3907029168) (v4.5) WDC_WD20EADS 1953513492 3907027055 (native=3907029168) (v4.7) WDC_WD20EARS 1953513496 3907027055 (native=3907029168) (v4.6) WDC_WD20EARS 1953513492 3907027055 (native=3907029168) (v4.7) --Strange------------Size--------Sectors- WDC_WD20EADS 1475363896 2950727856 (native=3907029168) (v4.7) Confused! WDC_WD1200JB 117187528 234375000->234375120 (v4.5) (capacity increase by kernel!) ST3320620AS 312567380 625134827 (?!?no HPA reported!) IC25N040ATCS04? 78140160 --SSD Model----------------Size--------Sectors- SSDSA2SH032G1GN_INTEL 31249968 62500000 INTEL_SSDSA2M080G2GC 78150712 156301488 HITACHI_HUS154545VLS300 439548952 879097968 Quote Link to comment
bubbaQ Posted February 16, 2011 Share Posted February 16, 2011 HDPARM does not look like a reliable method I wouldn't say that..... first, more recent versions of hdparm do OK, and you can do range checking to double-check the results it gives. Quote Link to comment
Joe L. Posted February 16, 2011 Share Posted February 16, 2011 Ok - so unRAID will tell me the sizes of the disks in the array. But how can I get the same size using a conventional Linux command? unMain is currently getting the disk size, but it is not exactly the same as what unRAID reports. I need a command (or series of commands) that will result in unRaid's number for disks not already in the array. Help! Thanks! I use something like this in the preclear_disk.sh theDisk=/dev/sda total_bytes=`fdisk -l $theDisk 2>/dev/null | grep "Disk $theDisk" | awk '{ print $5 }'` Joe L. Quote Link to comment
RobJ Posted February 17, 2011 Share Posted February 17, 2011 And a couple of other choices, you can use older hdparms with the 'hdparm -I' command, then grep for the LBA48 line. The sector count is at the end of that line, so you could use a command very similar to the one Joe gave. The sector count could then be used in a table lookup. Another possibility - include a recent version of hdparm with UnMENU/MyMain, renamed perhaps (unhdparm?). Then check the version of the local hdparm (hdparm -V I think), and use which ever is more current. Or always use your included hdparm, for completely consistent results. Quote Link to comment
SSD Posted February 17, 2011 Author Share Posted February 17, 2011 Sorry guys. Massively busy at work. Hope to work on this over the weekend. Quote Link to comment
SSD Posted February 23, 2011 Author Share Posted February 23, 2011 If you either have (1) a disk that has been precleared with the "-A" option or with 4K aligned partitions OR (2) a disk with an HPA that was created prior to unRAID 4.7 OR (3) a brand new disks that has not been precleared yet, please help me gather some information. Run the following command and post ther results in this thread: fdisk -lu /dev/sdX (the option is a dash followed by a lower case L followed by a lower case U where sdX = the device of the disk (the device page of unRAID will show the device ids) This is a non descructive test and is safe to run on array or non-array disks. While I'd prefer this for a 750G, 1T, 1.5T or 2T drive, I will take what I can get, esp for a disk with HPA! The output should look something like this. (This is for a 1T disk with no HPA and sector 63 alignment) root@Tower:~# fdisk -l /dev/sdh Disk /dev/sdh: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdh1 63 1953525167 976762552+ 83 Linux Partition 1 does not end on cylinder boundary. Quote Link to comment
BRiT Posted February 23, 2011 Share Posted February 23, 2011 These two drives were precleared with the MBR 4K alignment and are currently assigned to an unRAID 5.0 beta 4 array. # fdisk -lu /dev/sdg Disk /dev/sdg: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0c47d628 Device Boot Start End Blocks Id System /dev/sdg1 64 3907029167 1953514552 83 Linux # fdisk -lu /dev/sdh Disk /dev/sdh: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x081f1e23 Device Boot Start End Blocks Id System /dev/sdh1 64 3907029167 1953514552 83 Linux Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.