Hello! I woke up to 22 read errors. I think it may be a bad setting on my end but could I get someones input? Extended smart test passed with 0 error (attached)

 

I believe the screen shot of the actual errors are attached. Otherwise I dont know where to locate the logs for those disk error (I am new to unraid)

 

I should also note. On this same drive I received a UDMA_CRC_Error_Count 1 while pre clearing it on different computer and different sata cable.

lyoton-smart-20230109-1437.zip

lyoton-diagnostics-20230109-1830.zip

Edited January 9, 20233 yr by bluetwo12
Attached diagnostics

Also if someone looks at this. Could I get their opinion:

 

I used the server quite a bit during parity sync. I also paused it for about an hour to do things yesterday. 

Parity sync finished up sometime during the middle of the night and thats when these errors occured. This is not my parity drive.

 

Could any of this cause these errors?

SMART for disk1 looks fine. UDMA CRC error means the drive received inconsistent data based on checksum. This is almost always a connection problem, and the data is usually resent.

 

The SMART attributes are recorded by the drive firmware in the drive firmware, and can't be reset. This particular SMART attribute is almost never a disk problem, just something you need to take care of with the connections if you get a lot of them frequently.

 

You can click on the SMART warning on the Dashboard page to Acknowledge it and it will warn again if it increases.

 

More to follow

 

 

59 minutes ago, bluetwo12 said:

dont know where to locate the logs

Tools - Syslog, or the logs button on the main bar. This is only the current syslog (since reboot) since all of the OS is in RAM. Also, diagnostics includes current syslog, so I can see those errors there. Looks like parity sync had already completed before these.

 

19 minutes ago, bluetwo12 said:

used the server quite a bit during parity sync. I also paused it for about an hour to do things yesterday. 

Should not matter. Parity is maintained anyway even while being built. It just makes it work harder since it has to read and write disks when you use the array, and it has to go back where it was to read all disks to resume rebuilding parity (or a data disk). So it has to move around on the disks a lot more when you use the array while rebuilding.

 

 

Not entirely clear if this problem with disk1 is simply a connection issue though. Click on disk1 to get to its page, and run extended self-test on it.

Unrelated, but your appdata and system shares have files on the array, probably because you enabled Docker before you installed cache. We can work on that after disk1 test completes. Will take several hours, and it only shows progress every 10%

4 minutes ago, trurl said:

 

 

 

Not entirely clear if this problem with disk1 is simply a connection issue though. Click on disk1 to get to its page, and run extended self-test on it.

Was that smart zip not of the extended self test? Thats what it ran today for 433min according to the zip I attached

6 minutes ago, bluetwo12 said:

Was that smart zip not of the extended self test? Thats what it ran today for 433min according to the zip I attached

Sorry I missed that. Yes it looks OK. No disks are disabled and all data disks are mounted so that all looks good.

 

Check connections on disk1, SATA and power, both ends, including splitters.

 

You might run a parity check just to make sure parity build went OK and to test how things are working now.

 

 

 

 

 

Ill do that. I am concerned about the disk. Its under warranty but id rather not deal with the hassel if its not actually bad. 

 

as for the app data. Yeah that was a mess. Pretty sure I am having things be saved in the docker data that arent suppose to be as well

18 minutes ago, trurl said:

Sorry I missed that. Yes it looks OK. No disks are disabled and all data disks are mounted so that all looks good.

 

Check connections on disk1, SATA and power, both ends, including splitters.

 

You might run a parity check just to make sure parity build went OK and to test how things are working now.

 

 

 

 

 

Do disk read errors disappear when you restart the server?I guess so because the log files reset?

 

 

Just now, bluetwo12 said:

Do disk read errors disappear when you restart the server?I guess so because the log files reset?

Yes, you can also do Clear Stats on Main - Array Operation. Not exactly because the logs reset, everything resets except what can be reloaded from your configuration (config folder on flash, all the settings you have made in the webUI).

 

Unraid installs itself fresh into RAM from the archives on flash at each boot, and runs completely in RAM. Think of it as firmware. None of the OS is on your disks.

6 minutes ago, trurl said:

Yes, you can also do Clear Stats on Main - Array Operation. Not exactly because the logs reset, everything resets except what can be reloaded from your configuration (config folder on flash, all the settings you have made in the webUI).

 

Unraid installs itself fresh into RAM from the archives on flash at each boot, and runs completely in RAM. Think of it as firmware. None of the OS is on your disks.

 

Thanks! Running parity check. I swapped the sata cables on disk1/2 so ill know if something is up with that at least. All the connections seemed solid. Ill get back to you tomorrow with parity check results/ if there are any errors tomrrow.

28 minutes ago, bluetwo12 said:

saved in the docker data that arent suppose to be

I am using 46% of 20G docker.img with 16 dockers installed. Looks like you are using 63% of 20G. How many dockers?

25 minutes ago, trurl said:

I am using 46% of 20G docker.img with 16 dockers installed. Looks like you are using 63% of 20G. How many dockers?

Not that many.... lol

2 hours ago, trurl said:

63% of 20G

That might be OK with those dockers.

 

Any application writing to a path that isn't mapped is writing inside docker.img, simple as that.

8 hours ago, trurl said:

That might be OK with those dockers.

 

Any application writing to a path that isn't mapped is writing inside docker.img, simple as that.

Maybe it is set up then. Parity check still has a bit to go but I woke up with 19 errors on the same disk. I swapped both the power and sata cables between disk 1 and 2. So either the physical connector on the hdd is bad. Or I am guessing something else is bad. Im leaning towards trying to get it replaced. 

 

I attached the new diagnostics

lyoton-diagnostics-20230110-0712.zip

Also:

 

It's logged as a disk problem.

20 minutes ago, JorgeB said:

It's logged as a disk problem.

Aka. Needs replaced?

Most likely, you can run an extended SMART test, though these errors can sometimes be intermittent.

15 minutes ago, JorgeB said:

Most likely, you can run an extended SMART test, though these errors can sometimes be intermittent.

Yeah. I ran one and attached to to the original post and everything came out clean

One more question.

 

Since the RMA process is likely going to take awhile. Which option is better.

 

Move all data from the dying disk to the healthy disk? Then insert a new hdd?

 

Or just confirm parity, shut down array, insert new hdd (do the pre clear) and rebuild parity?

 

Im going to purchase another hdd as it is so either option is fine by me. Just dont know which is best.

Just rebuild the disk to a new disk, preclear optional.