drawde Posted July 20, 2021 Posted July 20, 2021 (edited) I messed up and forgot to get diagnostics before rebooting (doh!) and I'm currently rebuilding parity on a new drive. I've attached diagnostics anyways. I do have syslogs dating back to april that hopefully is helpful though. tower-diagnostics-20210719-2046.zip syslog.txt.log Edited July 20, 2021 by drawde redundant info Quote
trurl Posted July 20, 2021 Posted July 20, 2021 51 minutes ago, drawde said: rebuilding parity on a new drive Is the old parity still attached? Did you have a question? Quote
drawde Posted July 20, 2021 Author Posted July 20, 2021 (edited) 23 minutes ago, trurl said: Is the old parity still attached? Did you have a question? LOL sorry, yes i did have a question. Is the hdd likely dying or could it be something else? i was never good at deciphering the smart reports, any feedback or tips would be appreciated. hardware-wise all i've done so far is reseat the drive. but took it out of service already. It's only been a few months. drive is still attached and running an extended SMART currently. if smart comes up good was thinking of running a preclear or two on it. Edited July 20, 2021 by drawde Quote
itimpi Posted July 20, 2021 Posted July 20, 2021 It would help if you give the last part of the the serial number of the drive in question? It was not obvious to me from the diagnostics which drive you are asking about. Quote
drawde Posted July 20, 2021 Author Posted July 20, 2021 man, i really am messing up lol.. the drive in question is ST16000NM001G-2KK103 (sdt), also the only 16tb drive. Quote
trurl Posted July 20, 2021 Posted July 20, 2021 1 hour ago, drawde said: drive in question is ST16000NM001G-2KK103 (sdt), also the only 16tb drive. That is the model number, and since it is the only drive of that model, it is obvious which you mean. Better to just give the last 4 characters of the serial number, that will usually be enough to uniquely identify. The usually monitored SMART attributes for that disk look OK. If it passes extended test it should be good to use. Since you rebooted before getting any information we can't see what might have caused the disk to be disabled. All we can say is that a write to it failed so Unraid disabled it because it was no longer in sync. Actually, we don't really know that unless you confirm it, since those diagnostics only tell us that a new parity disk was assigned. Connection problems are much more common than disk problems. Quote
drawde Posted July 20, 2021 Author Posted July 20, 2021 ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-- 071 064 044 - 12246579 7 Seek_Error_Rate POSR-- 080 060 045 - 92287026 Thanks! Is that raw value the actual number of sectors? Are numbers this big consistent with the drive experiencing some failures and being disabled only once? Quote
drawde Posted July 20, 2021 Author Posted July 20, 2021 (edited) 29 minutes ago, trurl said: Since you rebooted before getting any information we can't see what might have caused the disk to be disabled. All we can say is that a write to it failed so Unraid disabled it because it was no longer in sync. Actually, we don't really know that unless you confirm it, since those diagnostics only tell us that a new parity disk was assigned. Next time I will remember to capture the diagnostics immediately. However I also attached logs that go back to April, not sure if there is anything useful there, but you can see when the drive actually first started having issues yesterday. Edited July 20, 2021 by drawde add Quote
JorgeB Posted July 20, 2021 Posted July 20, 2021 2 minutes ago, drawde said: Are numbers this big consistent with the drive experiencing some failures and being disabled only once? Those are normal with Seagate drives: https://forums.unraid.net/topic/86337-are-my-smart-reports-bad/?do=findComment&comment=800888 Quote
drawde Posted July 20, 2021 Author Posted July 20, 2021 (edited) not sure if there's a way to download a SMART self-test but got the following: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 2756 - Looks good to me. Going to run a preclear just for peace of mind before adding back into action (possibly as a 2nd parity for now). Thanks! EDIT: hmm, doesn't seem to want to mount under unassigned devices so i can run a preclear on it.. getting the following: Jul 20 17:31:19 Tower unassigned.devices: Adding disk '/dev/sdt1'... Jul 20 17:31:19 Tower unassigned.devices: Mount drive command: /sbin/mount -t xfs -o rw,noatime,nodiratime '/dev/sdt1' '/mnt/disks/ST16000NM001G-2KK103_ZL2ATVRA' Jul 20 17:31:19 Tower kernel: XFS (sdt1): Mounting V5 Filesystem Jul 20 17:31:19 Tower kernel: XFS (sdt1): Log inconsistent (didn't find previous header) Jul 20 17:31:19 Tower kernel: XFS (sdt1): failed to find log head Jul 20 17:31:19 Tower kernel: XFS (sdt1): log mount/recovery failed: error -5 Jul 20 17:31:19 Tower kernel: XFS (sdt1): log mount failed Jul 20 17:31:19 Tower unassigned.devices: Mount of '/dev/sdt1' failed: 'mount: /mnt/disks/ST16000NM001G-2KK103_ZL2ATVRA: can't read superblock on /dev/sdt1. ' i tried xfs_repair -v /dev/sdt1 but it just started spamming .'s. I'll wait until parity is finished rebuilding on my other drive and try again later. Edited July 20, 2021 by drawde Quote
trurl Posted July 20, 2021 Posted July 20, 2021 Since this was parity, it has no filesystem to mount, xfs or otherwise. You shouldn't need to mount it to preclear it. In fact, it doesn't make any sense to mount a disk to be precleared since mounting is for making the filesystem accessible, and even if it had a filesystem, preclear would destroy it. Quote
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.