dwoods99 Posted February 4, 2011 Share Posted February 4, 2011 parity ST32000542AS_5XW0000 25°C 1,953,513,492 disk1 WDC_WD20EARS-00M_WD-WMAZA000 30°C 1,953,514,552 disk2 WDC_WD20EARS-00M_WD-WCAZA000 28°C 1,953,514,552 disk3 WDC_WD20EARS-00M_WD-WMAZA001 27°C 1,953,514,552 disk4 WDC_WD20EARS-00M_WD-WCAZA001 29°C 1,953,514,552 disk5 WDC_WD20EARS-00S_WD-WCAVY000 34°C 1,953,514,552 disk6 WDC_WD20EARS-00M_WD-WCAZA002 32°C 1,953,514,552 Seriously? I can't assign the Seagate 2TB green drive because it's 60 blocks too small? It's already been pre-cleared, and I was adding last after data was copied to other disks. I was adding parity now so that it could spend the next 3-4 days building the parity check. What else can I do besides buying another 2TB WD green drive -- which needs 30+ hours to pre-clear? EDIT: added relevant syslog below (removed info on 3 x 1TB Seagates also in array) Feb 3 19:36:03 Tower kernel: mdcmd (38): stop Feb 3 19:36:03 Tower kernel: md1: stopping Feb 3 19:36:03 Tower kernel: md2: stopping Feb 3 19:36:03 Tower kernel: md3: stopping Feb 3 19:36:03 Tower kernel: md4: stopping Feb 3 19:36:03 Tower kernel: md5: stopping Feb 3 19:36:03 Tower kernel: md6: stopping Feb 3 19:36:04 Tower emhttp: shcmd (111): /etc/rc.d/rc.nfsd start | logger Feb 3 19:36:32 Tower emhttp: shcmd (112): modprobe -rw md-mod 2>&1 | logger Feb 3 19:36:32 Tower emhttp: shcmd (113): modprobe md-mod super=/boot/config/super.dat slots=0,0,8,0,8,16,8,32,8,48,8,64,8,80,0,0,8,112,0,0,8,144,8,160,8,176,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 2>&1 | logger Feb 3 19:36:32 Tower kernel: md: unRAID driver removed Feb 3 19:36:32 Tower kernel: xor: automatically using best checksumming function: pIII_sse Feb 3 19:36:32 Tower kernel: pIII_sse : 7420.000 MB/sec Feb 3 19:36:32 Tower kernel: xor: using function: pIII_sse (7420.000 MB/sec) Feb 3 19:36:32 Tower kernel: md: unRAID driver 1.1.1 installed Feb 3 19:36:32 Tower kernel: md: disk0 removed Feb 3 19:36:32 Tower kernel: md: import disk1: [8,0] (sda) WDC WD20EARS-00M WD-WMAZA1580982 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk2: [8,16] (sdb) WDC WD20EARS-00M WD-WCAZA1221569 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk3: [8,32] (sdc) WDC WD20EARS-00M WD-WMAZA0853254 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk4: [8,48] (sdd) WDC WD20EARS-00M WD-WCAZA1239546 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk5: [8,64] (sde) WDC WD20EARS-00S WD-WCAVY5637510 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk6: [8,80] (sdf) WDC WD20EARS-00M WD-WCAZA1137613 size: 1953514552 Feb 3 19:36:32 Tower kernel: md: import disk12: [8,176] (sdl) ST32000542AS 5XW1M28C size: 1953513492 Feb 3 19:36:32 Tower kernel: md: disk12 new disk Feb 3 19:36:32 Tower kernel: mdcmd (1): set md_num_stripes 2560 Feb 3 19:36:32 Tower kernel: mdcmd (2): set md_write_limit 768 Feb 3 19:36:32 Tower kernel: mdcmd (3): set md_sync_window 288 Feb 3 19:36:32 Tower kernel: mdcmd (4): set spinup_group 1 0 Feb 3 19:36:32 Tower kernel: mdcmd (5): set spinup_group 2 0 Feb 3 19:36:32 Tower kernel: mdcmd (6): set spinup_group 3 0 Feb 3 19:36:32 Tower kernel: mdcmd (7): set spinup_group 4 0 Feb 3 19:36:32 Tower kernel: mdcmd (: set spinup_group 5 0 Feb 3 19:36:32 Tower kernel: mdcmd (9): set spinup_group 6 0 Feb 3 19:36:32 Tower kernel: mdcmd (13): set spinup_group 12 0 Feb 3 19:36:34 Tower emhttp: shcmd (114): modprobe -rw md-mod 2>&1 | logger Feb 3 19:36:34 Tower emhttp: shcmd (115): modprobe md-mod super=/boot/config/super.dat slots=0,0,8,0,8,16,8,32,8,48,8,64,8,80,0,0,8,112,0,0,8,144,8,160,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 2>&1 | logger Feb 3 19:36:34 Tower kernel: md: unRAID driver removed Feb 3 19:36:34 Tower kernel: xor: automatically using best checksumming function: pIII_sse Feb 3 19:36:34 Tower kernel: pIII_sse : 7420.000 MB/sec Feb 3 19:36:34 Tower kernel: xor: using function: pIII_sse (7420.000 MB/sec) Feb 3 19:36:34 Tower kernel: md: unRAID driver 1.1.1 installed Feb 3 19:36:34 Tower kernel: md: disk0 removed Feb 3 19:36:34 Tower kernel: md: import disk1: [8,0] (sda) WDC WD20EARS-00M WD-WMAZA1580982 size: 1953514552 Feb 3 19:36:34 Tower kernel: md: import disk2: [8,16] (sdb) WDC WD20EARS-00M WD-WCAZA1221569 size: 1953514552 Feb 3 19:36:34 Tower kernel: md: import disk3: [8,32] (sdc) WDC WD20EARS-00M WD-WMAZA0853254 size: 1953514552 Feb 3 19:36:34 Tower kernel: md: import disk4: [8,48] (sdd) WDC WD20EARS-00M WD-WCAZA1239546 size: 1953514552 Feb 3 19:36:34 Tower kernel: md: import disk5: [8,64] (sde) WDC WD20EARS-00S WD-WCAVY5637510 size: 1953514552 Feb 3 19:36:34 Tower kernel: md: import disk6: [8,80] (sdf) WDC WD20EARS-00M WD-WCAZA1137613 size: 1953514552 Feb 3 19:36:34 Tower kernel: mdcmd (1): set md_num_stripes 2560 Feb 3 19:36:34 Tower kernel: mdcmd (2): set md_write_limit 768 Feb 3 19:36:34 Tower kernel: mdcmd (3): set md_sync_window 288 Feb 3 19:36:34 Tower kernel: mdcmd (4): set spinup_group 1 0 Feb 3 19:36:34 Tower kernel: mdcmd (5): set spinup_group 2 0 Feb 3 19:36:34 Tower kernel: mdcmd (6): set spinup_group 3 0 Feb 3 19:36:34 Tower kernel: mdcmd (7): set spinup_group 4 0 Feb 3 19:36:34 Tower kernel: mdcmd (: set spinup_group 5 0 Feb 3 19:36:34 Tower kernel: mdcmd (9): set spinup_group 6 0 Feb 3 19:36:38 Tower emhttp: shcmd (116): modprobe -rw md-mod 2>&1 | logger Feb 3 19:36:38 Tower emhttp: shcmd (117): modprobe md-mod super=/boot/config/super.dat slots=8,176,8,0,8,16,8,32,8,48,8,64,8,80,0,0,8,112,0,0,8,144,8,160,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 2>&1 | logger Feb 3 19:36:38 Tower kernel: md: unRAID driver removed Feb 3 19:36:38 Tower kernel: xor: automatically using best checksumming function: pIII_sse Feb 3 19:36:38 Tower kernel: pIII_sse : 7420.000 MB/sec Feb 3 19:36:38 Tower kernel: xor: using function: pIII_sse (7420.000 MB/sec) Feb 3 19:36:38 Tower kernel: md: unRAID driver 1.1.1 installed Feb 3 19:36:38 Tower kernel: md: import disk0: [8,176] (sdl) ST32000542AS 5XW1M28C size: 1953513492 Feb 3 19:36:38 Tower kernel: md: disk0 replaced Feb 3 19:36:38 Tower kernel: md: import disk1: [8,0] (sda) WDC WD20EARS-00M WD-WMAZA1580982 size: 1953514552 Feb 3 19:36:38 Tower kernel: md: import disk2: [8,16] (sdb) WDC WD20EARS-00M WD-WCAZA1221569 size: 1953514552 Feb 3 19:36:38 Tower kernel: md: import disk3: [8,32] (sdc) WDC WD20EARS-00M WD-WMAZA0853254 size: 1953514552 Feb 3 19:36:38 Tower kernel: md: import disk4: [8,48] (sdd) WDC WD20EARS-00M WD-WCAZA1239546 size: 1953514552 Feb 3 19:36:38 Tower kernel: md: import disk5: [8,64] (sde) WDC WD20EARS-00S WD-WCAVY5637510 size: 1953514552 Feb 3 19:36:38 Tower kernel: md: import disk6: [8,80] (sdf) WDC WD20EARS-00M WD-WCAZA1137613 size: 1953514552 Feb 3 19:36:38 Tower kernel: mdcmd (1): set md_num_stripes 2560 Feb 3 19:36:38 Tower kernel: mdcmd (2): set md_write_limit 768 Feb 3 19:36:38 Tower kernel: mdcmd (3): set md_sync_window 288 Feb 3 19:36:38 Tower kernel: mdcmd (4): set spinup_group 0 0 Feb 3 19:36:38 Tower kernel: mdcmd (5): set spinup_group 1 0 Feb 3 19:36:38 Tower kernel: mdcmd (6): set spinup_group 2 0 Feb 3 19:36:38 Tower kernel: mdcmd (7): set spinup_group 3 0 Feb 3 19:36:38 Tower kernel: mdcmd (: set spinup_group 4 0 Feb 3 19:36:38 Tower kernel: mdcmd (9): set spinup_group 5 0 Link to comment
aiden Posted February 4, 2011 Share Posted February 4, 2011 Well, you could move all the data from one of the data drives to the Seagate, make it a data replacement drive, and then rebuild parity on the old WD data drive. Assuming you precleared the data drives before using them, you should be able to trust any of them. Link to comment
BRiT Posted February 4, 2011 Share Posted February 4, 2011 Please post a full syslog so we can see what's going on. Link to comment
dwoods99 Posted February 4, 2011 Author Share Posted February 4, 2011 edited OP. Copying from 1 to another is an option... I just can't see how 60 blocks should matter. unRAID should be more forgiving. Link to comment
BRiT Posted February 4, 2011 Share Posted February 4, 2011 I appreciate you trying to only post the relevant parts, but in this case there could be more items of interest not included in your snippets. Could you please attach a full syslog (zipped up if need be) so we can see if there's any sort of HPA detected and what the native size of the drive is? Link to comment
dwoods99 Posted February 4, 2011 Author Share Posted February 4, 2011 I'm new to unRAID but not to Linux... so I really don't see anything else relevant at the time I stopped the array to add the parity drive. You mentioned HPA, all the WD green drives were pre-cleared with sector 64 (-A option). I also double-checked the Seagate 2 TB that I want to add, and it is also sector 64. Device Model: ST32000542AS Serial Number: 5XW1M28C Firmware Version: CC35 User Capacity: 2,000,397,852,160 bytes Disk /dev/sdl: 2000.3 GB, 2000397852160 bytes 1 heads, 63 sectors/track, 62016302 cylinders, total 3907027055 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdl1 64 3907027054 1953513495+ 83 Linux Link to comment
Spectrum Posted February 4, 2011 Share Posted February 4, 2011 Take a look at Joe L.'s post here for something similar. Do you have a Gigabyte motherboard? They are notorious for 'helping you' by saving a copy of your bios on one of your hard drives. Link to comment
dwoods99 Posted February 4, 2011 Author Share Posted February 4, 2011 Ok, rebooted and took another look at the syslog looking for HPA and the 2TB Seagate drive in question does have it. My motherboard is an Intel board and chipset, but my Win-XP PC is Gigabyte and I do believe I first formatted the drive on there to check it out; to make sure it wasn't a dud. I also used the PC to upgrade it to firmware CC35. The culprit (ST32000542AS) shows up as /dev/sdl (ata10.01) Feb 3 21:43:58 Tower kernel: scsi9 : ata_piix Feb 3 21:43:58 Tower kernel: scsi10 : ata_piix Feb 3 21:43:58 Tower kernel: ata9: SATA max UDMA/133 cmd 0xd0e0 ctl 0xd0d0 bmdma 0xd0a0 irq 19 Feb 3 21:43:58 Tower kernel: ata10: SATA max UDMA/133 cmd 0xd0c0 ctl 0xd0b0 bmdma 0xd0a8 irq 19 Feb 3 21:43:58 Tower kernel: ata9.01: failed to IDENTIFY (I/O error, err_mask=0x2) Feb 3 21:43:58 Tower kernel: ata10.00: ATA-8: ST31000528AS, CC38, max UDMA/133 Feb 3 21:43:58 Tower kernel: ata10.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) Feb 3 21:43:58 Tower kernel: ata10.01: HPA detected: current 3907027055, native 3907029168 Feb 3 21:43:58 Tower kernel: ata10.01: ATA-8: ST32000542AS, CC35, max UDMA/133 Feb 3 21:43:58 Tower kernel: ata10.01: 3907027055 sectors, multi 16: LBA48 NCQ (depth 0/32) Feb 3 21:43:58 Tower kernel: ata10.00: configured for UDMA/133 Feb 3 21:43:58 Tower kernel: ata10.01: configured for UDMA/133 Feb 3 21:43:58 Tower kernel: ata9.01: failed to IDENTIFY (I/O error, err_mask=0x2) Feb 3 21:43:58 Tower kernel: ata9.01: failed to IDENTIFY (I/O error, err_mask=0x2) Feb 3 21:43:58 Tower kernel: ata9.00: ATA-8: ST31000333AS, CC1H, max UDMA/133 Feb 3 21:43:58 Tower kernel: ata9.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) Feb 3 21:43:58 Tower kernel: ata9.00: configured for UDMA/133 Feb 3 21:43:58 Tower kernel: scsi 9:0:0:0: Direct-Access ATA ST31000333AS CC1H PQ: 0 ANSI: 5 Feb 3 21:43:58 Tower kernel: scsi 10:0:0:0: Direct-Access ATA ST31000528AS CC38 PQ: 0 ANSI: 5 Feb 3 21:43:58 Tower kernel: scsi 10:0:1:0: Direct-Access ATA ST32000542AS CC35 PQ: 0 ANSI: 5 Feb 3 21:43:58 Tower kernel: sd 9:0:0:0: [sdj] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) Feb 3 21:43:58 Tower kernel: sd 9:0:0:0: [sdj] Write Protect is off Feb 3 21:43:58 Tower kernel: sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00 Feb 3 21:43:58 Tower kernel: sd 10:0:0:0: [sdk] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) Feb 3 21:43:58 Tower kernel: sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 3 21:43:58 Tower kernel: sd 10:0:0:0: [sdk] Write Protect is off Feb 3 21:43:58 Tower kernel: sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00 Feb 3 21:43:58 Tower kernel: sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 3 21:43:58 Tower kernel: sdj: Feb 3 21:43:58 Tower kernel: sdk: sdj1 Feb 3 21:43:58 Tower kernel: sdk1 Feb 3 21:43:58 Tower kernel: sd 9:0:0:0: [sdj] Attached SCSI disk Feb 3 21:43:58 Tower kernel: sd 10:0:0:0: [sdk] Attached SCSI disk Feb 3 21:43:58 Tower kernel: sd 10:0:1:0: [sdl] 3907027055 512-byte logical blocks: (2.00 TB/1.81 TiB) Feb 3 21:43:58 Tower kernel: sd 10:0:1:0: [sdl] Write Protect is off Feb 3 21:43:58 Tower kernel: sd 10:0:1:0: [sdl] Mode Sense: 00 3a 00 00 Feb 3 21:43:58 Tower kernel: sd 10:0:1:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 3 21:43:58 Tower kernel: sdl: sdl1 Feb 3 21:43:58 Tower kernel: sd 10:0:1:0: [sdl] Attached SCSI disk So with this line and reading the thread linked in previous post, Feb 3 21:43:58 Tower kernel: ata10.01: HPA detected: current 3907027055, native 3907029168 I tried the following commands (array is down)... root@Tower:~# hdparm -N p3907029168 /dev/sdl /dev/sdl: setting max visible sectors to 3907029168 (permanent) SET_MAX_ADDRESS failed: Input/output error max sectors = 3907027055/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:~# hdparm -N /dev/sdl /dev/sdl: max sectors = 3907027055/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) root@Tower:~# which does not appear to have worked. Did I miss something or do I need to use Seatools now to try and remove HPA? Link to comment
dgaschk Posted February 4, 2011 Share Posted February 4, 2011 Before using seatools you can try hdparm -N p1953525168 /dev/sdX (where X is the letter of your drive) see here for further detail: http://lime-technology.com/forum/index.php?topic=10577.0 Link to comment
dwoods99 Posted February 4, 2011 Author Share Posted February 4, 2011 @dgaschk, that number you're suggesting from that thread is for a 1TB drive. As per my previous post, I tried that command with the 'native' value I got from the syslog file. ::: SOLVED::: I had a previous Seatools boot-up CD, so I hooked up an old IDE CD-ROM drive to the server. Started it up, selected the 2TB Seagate, ran "C" for "Clearing Maximum drive size", exit and reboot. (disconnect CD drive) After the reboot I checked with hdparm (drive was now allocated to sdm instead of sdl) # hdparm -N /dev/sdm /dev/sdm: max sectors = 3907029168/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?) First number ends with 168 so all good now. Re-assigned this drive as the parity drive and the size now matches all the others with 1,953,514,552 Started array and now it's doing the parity-sync. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.