SMART errors on parity drive

[drawde]

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

[trurl]

51 minutes ago, drawde said:

rebuilding parity on a new drive

Is the old parity still attached? Did you have a question?

[drawde]

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

[itimpi]

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.

[drawde]

man, i really am messing up lol.. the drive in question is ST16000NM001G-2KK103 (sdt), also the only 16tb drive.

[trurl]

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.

[drawde]

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?

[drawde]

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

[JorgeB]

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

 

[drawde]

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

[trurl]

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.