March 20, 20188 yr Hello Curious what I should do I'm getting 65000000 read errors on a different disk during a data rebuild can i stop it reboot and try again thanks for your time, Bobby
March 20, 20188 yr Stop it. Check connections. Reboot. Try again. and / or Go to Tools - Diagnostics and post complete zip.
March 20, 20188 yr Author it was having a read error every 8 sectors ... I just upgraded to 6.5.0 a few days before this happened trying to get diagnostics to save ... but it's not cooperating
March 20, 20188 yr Author Here's the last diagnostics I could get storage-diagnostics-20180320-1307.zip
March 20, 20188 yr Author Stopped it rebooted it one drive was attempting to rebuild drive 8 is missing Monthly parity checks no smart warnings on this array one drive parity two drives died within twelve hours will power down for the day and start looking at it tomorrow
March 20, 20188 yr 41 minutes ago, perfessor101 said: it was having a read error every 8 sectors ... Each sector is 512 byte and most file systems have the OS operate on 4kB blocks - so each 4kB block represents 8 sectors.
March 20, 20188 yr 1 hour ago, perfessor101 said: two drives died within twelve hours Most likely something other than the actual drives; connections, cables, controller, power.
March 21, 20188 yr Author That drive will be on a backplane connected a multilane cable that breaks out to motherboard data ports the original drive that died will be on a backplane to multilane cable to an aoc-saslp-mv8 it has a xfx power supply (that came with a mis/cross wired 4 pin molex connector i reseated all the drives and it occured again will try reseating all motherboard connections
March 21, 20188 yr Author would it be possible to run a dd /dev/sds to /dev/null to see if the drive errors when not doing a parity check?
March 21, 20188 yr SASLP can drop disks without reason, it doesn't happen to all users but to enough that they are no longer recommended, a change in unRAID version can trigger the issue.
March 21, 20188 yr Author I never had the drive dropping issue ... atleast not enough that it could be considered an issue ... most times I've rebuilt the array the drive that needed replacing would make it through a preclear dropped back to 6.4.1 and will try data rebuild again ... after I was going to try reading the drive in another server with dd if=/dev/sdx of=/dev/null to see if it can do that without error would this be suggested?
March 21, 20188 yr 1 minute ago, perfessor101 said: I never had the drive dropping issue ... Yes, but 18 hours ago, perfessor101 said: I just upgraded to 6.5.0 a few days before this happened like I mentioned, any kernel change can trigger it, though I not saying that was the problem, but it's a possibility.
March 21, 20188 yr 1 minute ago, perfessor101 said: most times I've rebuilt the array the drive that needed replacing would make it through a preclear Which of course means there was nothing wrong with the drive on those occasions and the reason it had to be rebuilt was because of another issue.
March 21, 20188 yr 2 minutes ago, perfessor101 said: would this be suggested? Just run an extended SMART test, this will test the drive only, so even it the SASLP was the problem it won't affect the testing.
March 21, 20188 yr Author 18 minutes ago, trurl said: Which of course means there was nothing wrong with the drive on those occasions and the reason it had to be rebuilt was because of another issue. doh ... sorry ... it doesn't help when i forget the "n't" in wouldn't makes things more complicated for everyone there were about five dead drives that wouldn't make it through a preclear ... two of those would lock up any of my servers completely until removed and the system rebooted I have one unRaid with 23 drives for mostly media utilizing aoc-saslp-mv8s from when they were in vogue the other server for system backups has 11 drives in the array and 7 drives as unassigned devices after removing from the main array or from my esxi 5 system utilizing aoc-saslp2-mv8s from when they were in vogue there were two others that made it through a preclear with most of their errors stabilized after
March 21, 20188 yr Author the drives that dropped out of the array are both in my backup server with the aoc-saslp2-mv8's running extended self tests ... if the drives are good in that server I may swap all the drives from one system to the other the second failed drive was attached to the gigabyte GA-990FXA-UD7 motherboard sata ports
March 22, 20188 yr Author the original drive that failed that was connect to a aoc-saslp-mv8 is a 2TB WD EARX and is at 90% in its extended selftest after 10 hours the second drive that failed that was connected to the GA-990FXA-UD7 motherboard port passed its extended selftest in under 6 hours would it be worth trying a conveyance test on both in the morning ? will try a dd from the one that passed its self test to /dev/null to see if it has problems under heavy read conditions
March 22, 20188 yr 3 hours ago, perfessor101 said: would it be worth trying a conveyance test on both in the morning ? No, extended test is enough, conveyance test is to detect shipping damage.
March 22, 20188 yr Author both drives finished their self tests eventually am trying a quick dd to dev null from each drive sorry for the delays ... I'm working nights and have been terribly tired all week
March 22, 20188 yr Author okay I have an empty 2TB drive on the backup server so instead of just sending the data to /dev/null I will rsync it over via rsync -aihrvn --stats --progress /mnt/disks/WDC_WD20EARX-00PASB0_WD-WCAZAK497085/ /mnt/disks/WDC_WD20EARS-00J2GB0_WD-WCAYY0032646/ which may be a more constructive test
Archived
This topic is now archived and is closed to further replies.