Hoopster Posted August 26, 2012 Share Posted August 26, 2012 I have tried twice now to upgrade my parity disk from a 2TB WD to a 3TB Hitachi. It has failed both times at or near the end of the process (I have not been at the console when it finished/errored out either time). This last time I got a red dot with two write errors. Disk format shows: GPT: 4k-aligned (factory-erased) I am running unRAID 5 beta 14. Here is the syslog: Aug 26 06:18:56 MediaNAS emhttp: Start array... Aug 26 06:18:56 MediaNAS kernel: mdcmd (18): start UPGRADE_DISK Aug 26 06:18:56 MediaNAS kernel: unraid: allocating 23480K for 1280 stripes (4 disks) Aug 26 06:18:56 MediaNAS kernel: md1: running, size: 732574552 blocks Aug 26 06:18:56 MediaNAS kernel: md2: running, size: 1953514552 blocks Aug 26 06:18:56 MediaNAS kernel: md3: running, size: 1953514552 blocks Aug 26 06:18:57 MediaNAS emhttp: shcmd (92): udevadm settle Aug 26 06:18:57 MediaNAS emhttp: shcmd (93): /usr/local/sbin/emhttp_event array_started Aug 26 06:18:57 MediaNAS emhttp_event: array_started Aug 26 06:18:57 MediaNAS emhttp: Mounting disks... Aug 26 06:18:57 MediaNAS emhttp: shcmd (94): mkdir /mnt/disk1 Aug 26 06:18:57 MediaNAS emhttp: shcmd (95): mkdir /mnt/disk2 Aug 26 06:18:57 MediaNAS emhttp: shcmd (96): mkdir /mnt/disk3 Aug 26 06:18:57 MediaNAS emhttp: shcmd (97): mkdir /mnt/cache Aug 26 06:18:57 MediaNAS emhttp: shcmd (98): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Aug 26 06:18:57 MediaNAS emhttp: shcmd (99): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/sdd1 /mnt/cache |& logger Aug 26 06:18:57 MediaNAS emhttp: shcmd (100): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Aug 26 06:18:57 MediaNAS emhttp: shcmd (101): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Aug 26 06:18:57 MediaNAS kernel: mdcmd (19): check CORRECT Aug 26 06:18:57 MediaNAS kernel: md: recovery thread woken up ... Aug 26 06:18:57 MediaNAS kernel: md: recovery thread syncing parity disk ... Aug 26 06:18:57 MediaNAS kernel: write_file: error 30 opening /boot/config/super.dat Aug 26 06:18:57 MediaNAS kernel: md: could not write superblock from /boot/config/super.dat Aug 26 06:18:57 MediaNAS kernel: md: using 1536k window, over a total of 2930266532 blocks. Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md2): using ordered data mode Aug 26 06:18:57 MediaNAS kernel: reiserfs: using flush barriers Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md3): using ordered data mode Aug 26 06:18:57 MediaNAS kernel: reiserfs: using flush barriers Aug 26 06:18:57 MediaNAS kernel: REISERFS (device sdd1): found reiserfs format "3.6" with standard journal Aug 26 06:18:57 MediaNAS kernel: REISERFS (device sdd1): using ordered data mode Aug 26 06:18:57 MediaNAS kernel: reiserfs: using flush barriers Aug 26 06:18:57 MediaNAS kernel: REISERFS (device sdd1): journal params: device sdd1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 26 06:18:57 MediaNAS kernel: REISERFS (device sdd1): checking transaction log (sdd1) Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md1): using ordered data mode Aug 26 06:18:57 MediaNAS kernel: reiserfs: using flush barriers Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md3): checking transaction log (md3) Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md1): checking transaction log (md2) Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md2): checking transaction log (md2) Aug 26 06:18:57 MediaNAS kernel: REISERFS (device sdd1): Using r5 hash to sort names Aug 26 06:18:57 MediaNAS emhttp: shcmd (102): chmod 770 '/mnt/cache' Aug 26 06:18:57 MediaNAS emhttp: shcmd (103): chown nobody:users '/mnt/cache' Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md1): Using r5 hash to sort names Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md2): Using r5 hash to sort names Aug 26 06:18:57 MediaNAS kernel: REISERFS (device md3): Using r5 hash to sort names Aug 26 06:18:58 MediaNAS emhttp: shcmd (104): chmod 770 '/mnt/disk2' Aug 26 06:18:58 MediaNAS emhttp: shcmd (105): chmod 770 '/mnt/disk1' Aug 26 06:18:58 MediaNAS emhttp: shcmd (106): chown nobody:users '/mnt/disk2' Aug 26 06:18:58 MediaNAS emhttp: shcmd (107): chown nobody:users '/mnt/disk1' Aug 26 06:18:58 MediaNAS emhttp: shcmd (108): chmod 770 '/mnt/disk3' Aug 26 06:18:58 MediaNAS emhttp: shcmd (109): chown nobody:users '/mnt/disk3' Aug 26 06:18:58 MediaNAS emhttp: shcmd (110): mkdir /mnt/user0 Aug 26 06:18:58 MediaNAS emhttp: shcmd (111): /usr/local/sbin/shfs /mnt/user0 -disks 14 -o noatime,big_writes,allow_other,default_permissions,use_ino Aug 26 06:18:58 MediaNAS emhttp: shcmd (112): mkdir /mnt/user Aug 26 06:18:58 MediaNAS emhttp: shcmd (113): /usr/local/sbin/shfs /mnt/user -disks 15 2000000 -o noatime,big_writes,allow_other,default_permissions,use_ino Aug 26 06:18:58 MediaNAS emhttp: shcmd (114): crontab -c /etc/cron.d - <<< "# Generated mover schedule: 40 3 * * * /usr/local/sbin/mover |& logger" Aug 26 06:18:58 MediaNAS emhttp: shcmd (115): /usr/local/sbin/emhttp_event disks_mounted Aug 26 06:18:58 MediaNAS emhttp_event: disks_mounted Aug 26 06:18:58 MediaNAS emhttp: shcmd (116): :>/etc/samba/smb-shares.conf Aug 26 06:18:58 MediaNAS emhttp: Restart SMB... Aug 26 06:18:58 MediaNAS emhttp: shcmd (117): killall -HUP smbd Aug 26 06:18:58 MediaNAS emhttp: shcmd (118): ps axc | grep -q rpc.mountd Aug 26 06:18:58 MediaNAS emhttp: _shcmd: shcmd (118): exit status: 1 Aug 26 06:18:58 MediaNAS emhttp: shcmd (119): /usr/local/sbin/emhttp_event svcs_restarted Aug 26 06:18:58 MediaNAS emhttp_event: svcs_restarted Aug 26 07:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 08:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 09:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 10:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 11:02:30 MediaNAS kernel: mdcmd (20): spindown 1 Aug 26 11:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 12:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 12:32:31 MediaNAS kernel: mdcmd (21): spindown 1 Aug 26 13:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 13:45:09 MediaNAS kernel: attempt to access beyond end of device Aug 26 13:45:09 MediaNAS kernel: sdb1: rw=1, want=4294967296, limit=4294967295 Aug 26 13:45:09 MediaNAS kernel: attempt to access beyond end of device Aug 26 13:45:09 MediaNAS kernel: md: disk0 write error Aug 26 13:45:09 MediaNAS kernel: sdb1: rw=1, want=4294967304, limit=4294967295 Aug 26 13:45:09 MediaNAS kernel: handle_stripe write error: 4294967288/0, count: 1 Aug 26 13:45:09 MediaNAS kernel: md: md_do_sync: got signal, exit... Aug 26 13:45:09 MediaNAS kernel: md: disk0 write error Aug 26 13:45:09 MediaNAS kernel: handle_stripe write error: 4294967296/0, count: 1 Aug 26 13:45:09 MediaNAS kernel: write_file: error 30 opening /boot/config/super.dat Aug 26 13:45:09 MediaNAS kernel: md: could not write superblock from /boot/config/super.dat Aug 26 13:45:09 MediaNAS kernel: md: recovery thread sync completion status: -4 Aug 26 13:45:09 MediaNAS kernel: md: recovery thread woken up ... Aug 26 13:45:09 MediaNAS kernel: write_file: error 30 opening /boot/config/super.dat Aug 26 13:45:09 MediaNAS kernel: md: could not write superblock from /boot/config/super.dat Aug 26 13:45:09 MediaNAS kernel: md: recovery thread has nothing to resync Aug 26 14:11:47 MediaNAS kernel: mdcmd (22): spindown 2 Aug 26 14:11:48 MediaNAS kernel: mdcmd (23): spindown 3 Aug 26 14:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" Aug 26 14:45:11 MediaNAS kernel: mdcmd (24): spindown 0 Aug 26 15:14:01 MediaNAS crond[1160]: failed parsing crontab for user root: cron="" The critical errors appear to be related to "attempt to access beyond end of device" and "could not write superblock from /boot/config/super.dat" messages I ran a preclear twice, both of which the drive passed. At the end it reported that it could not write to the Preclear_Reports directory as it was a read-only filesystem, so, I have no saved preclear report for the disk. After the first preclear, I ran a chkdsk on the flash drive. I was able to write to it. After the second failed with the same error, I copied everything off the flash drive, reformatted, copied everything back and ran the make_bootable.bat file. Again, I was able to write to the flash drive by copying files to it. After rebooting, I stopped the array, unassigned the old parity drive, assigned the new parity drive and started the array which started a parity sync. No joy in getting upgraded. I also need to upgrade an array disk and add two more disks (all 3tb), but, I can't proceed until I get a valid 3TB parity drive. Any ideas what I can do to get past this problem? Am I doing something wrong? Link to comment
Hoopster Posted August 27, 2012 Author Share Posted August 27, 2012 Apparently, some unRAID users who experienced the " attempt to access beyond end of device" error had HPA problems with Gigabyte motherboards. My motherboard is the Biostar TH61-ITX. It does have a UEFI bios. I precleared the drive with -A and the unRAID default is 4K aligned. There is some question as to whether or not this 3TB parity drive is advanced format. Some reports say yes, others say no. It is the Hitachi 7K3000 model #HDS723030ALA640. However, I also understand that it really should not matter and that it can be formatted with 4k blocks regardless; which is what I did. Another thread with a similar problem suggests that just reformatting the drive solved the problem and the parity sync worked after unRAID reported the format as GPT: 4K aligned rather than GPT:4K aligned (factory erased). If this may help, can I reformat from a Telnet command line as I do not see anywhere in the web interface under disk management (or anywhere else) to do this. I'm not a Linux expert, what is the proper fdisk command line to reformat the drive? I am trying to avoid yet another lengthy preclear (takes 31 hours on this drive) as I have done it twice and it passed both times. Would reformatting the flash drive take care of the "read-only filesystem error that prevented the preclear reports from being written? Link to comment
Joe L. Posted August 27, 2012 Share Posted August 27, 2012 All drives over 2.2 terabytes will get a GPT partition, it is always is 4K alligned. A protective MBR record starting a second 1 is always put into place to fool older non GPT aware utilities. does not matter if the drive is a advanced format or not, All disks will work perfectly with the GPT partition. Link to comment
Hoopster Posted August 27, 2012 Author Share Posted August 27, 2012 All drives over 2.2 terabytes will get a GPT partition, it is always is 4K alligned. A protective MBR record starting a second 1 is always put into place to fool older non GPT aware utilities. does not matter if the drive is a advanced format or not, All disks will work perfectly with the GPT partition. OK, that confirms what I thought I was reading. Any ideas how I can solve the problems with getting unRAID to accept the new parity drive? Since my licensed flash drive is the Kingston reader, I have purchased a new micro SD card and formatted and copied the v5 beta 14 files and my add-ons on to it. I have now booted with that new flash card, so, hopefully, I won't be getting the read-only filesystem errors if the problem was a bad micro SD card. I have put the old parity drive back in the system so I am not running unprotected while I get this figured out. Link to comment
Hoopster Posted August 28, 2012 Author Share Posted August 28, 2012 OK, it looks like no one has any ideas on this. I put my old 2 TB parity drive back in the array. It rebuilt with 23 parity sync errors. I thought that was odd since it was the same drive on which I had done a parity rebuild just a couple of days before and the data on the array drives had not changed. I am now using a new micro SD card in the Kingston MobileLite reader since it appears the old one had some corruption as every write attempt to it produced a read-only file system error. I am running another preclear on the new 3TB Hitachi and will try, once again, to get it in the system as a new parity drive when the preclear finishes. I've got another 5-6 hours on the preclear and then 8-9 hours for a parity sync to this drive. Hopefully, that does not yet again end in an "attempt to access beyond the end of device" error. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.