Newbie question about 2743378 errors from parity check.


Recommended Posts

6 weeks ago I ended up with a spare 128G SSD so thought since my 512G cache drive (old hybdrid momentus) was hardly touched I'd just swap in the 128G.

Like a newbie I tried to follow some forum posts but no matter how I tried I was never able to "move" the plex data so the 512 Drive went back in not to lose the libraries. No problem, I was just basically tinkering anyways. I rebooted UNRAID a few times with the 128G SSD but my PLEX data was always missing as I assume MOVING never worked.

 

After replacing the original back in,  UNRAID wanted to parity check.

The parity finished and I have the reminder "Last checked on Sat 10 Dec 2016 11:01:21 PM EST (34 days ago), finding 2743378 errors."

I have 5 4T WD RED drives that show 0 errors so I wasn't too worried.

This past week I needed some backups to  restore a laptop that I had created with Acronis True Image and 3 of them failed.

The file were on kept on UNRAID and pretty large 25G, 47G, 121G.

Normally I would just assume that Acronis is just true to form and the most unreliable backup known to man but wondered if maybe it goes back to the parity problems.

 

I was able to restore the laptop drive anyways but does anyone think it is a hard drive problem?

 

UNRAID seems pretty happy and running smooth every day without warnings.

 

Link to comment

Yes, of course you're right but I saw no errors besides the parity check and everything appeared to be running smooth up to that point and still now.

BTW, I have 2 parity drive (both 4T).

 

When I re-attached the 512G cache drive and everything came up rosy besides the parity errors I thought perhaps the 128SSD was at fault.

 

Thank you for the reply.

 

nasa2-diagnostics-20170113-1611.zip

Link to comment

Am I reading the SMART data from the 2 Seagate ( 2 Parity Drives) drives right ?

 

Seagate 1 Drive 191 hours

1 Raw_Read_Error_Rate    0x000f  119  099  006    Pre-fail  Always      -      233187568

 

Seagate 2 Drive 191 hours

1 Raw_Read_Error_Rate    0x000f  113  099  006    Pre-fail  Always      -      50534984

 

Both these drives are less than a year old...

 

 

Link to comment

I rebooted UNRAID a few times with the 128G SSD but my PLEX data was always missing as I assume MOVING never worked.

Rebooting seldom fixes anything.

 

Your comment about MOVING, plus some things in your syslog from Fix Common Problems makes me wonder whether you really understand the various setting for Use cache disk.

 

Yes writes to cache and moves from cache to array.

Prefer writes to cache if it can and moves from array to cache.

Only writes to cache and doesn't move.

No doesn't write to cache and doesn't move.

After replacing the original back in,  UNRAID wanted to parity check.

The parity finished and I have the reminder "Last checked on Sat 10 Dec 2016 11:01:21 PM EST (34 days ago), finding 2743378 errors."

So does this mean you have another parity check since the one that had millions of errors? If so, did it have zero errors?

... Acronis is just true to form and the most unreliable backup known to man...

Always worked well for me

I was able to restore the laptop drive anyways but does anyone think it is a hard drive problem?

 

UNRAID seems pretty happy and running smooth every day without warnings.

 

Since we don't have any diagnostics from the bad parity check not much to go on.

Am I reading the SMART data from the 2 Seagate ( 2 Parity Drives) drives right ?

 

Seagate 1 Drive 191 hours

1 Raw_Read_Error_Rate    0x000f  119  099  006    Pre-fail  Always      -      233187568

 

Seagate 2 Drive 191 hours

1 Raw_Read_Error_Rate    0x000f  113  099  006    Pre-fail  Always      -      50534984

 

Both these drives are less than a year old...

 

 

We don't usually monitor that particular attribute. Known ATA S.M.A.R.T. attributes

SMART for all drives looks OK.

Link to comment

Very much appreciate the replies.

 

Should I go ahead and do another parity check?

You didn't answer my question which I put in bold so you wouldn't miss it.

So does this mean you have another parity check since the one that had millions of errors? If so, did it have zero errors?

 

What does it say now about the last parity check?

Link to comment

Again, thanks for all help.

 

Yes I have notifications setup.

 

I have not tried to downsize to the 128SSD after the original failure.

I do realize I have to move the plex info first from the cache drive.

I will try again after a more diligent search on these forums for the proper procedure.

 

 

I'm also thinking of going back to a 1 drive parity instead of 2 and putting the 2nd 4T parity drive into the array as space is getting tight and the wallet seems closed to a new drive...

 

 

Link to comment

You can remove parity2 by setting a new config. Probably the simplest thing to do would be to just go ahead and add it as a data disk in a new slot when you do the new config and then rebuild parity1 and format the new data disk.

 

Another (better) possibility would be to tell it parity1 is valid when you do a new config without parity2, then add the old parity2 to a new data slot and let unRAID clear it and format it. This method would have the advantage of keeping you parity protected, and since unRAID will clear the disk for you instead of making you preclear it, it should be about as quick as the other method that would require you to rebuild parity.

 

Let us know if you need further clarification.

Link to comment

Looking over the replacing cache drive guide I noticed in my haste that did not follow the guide at the bottom first as not only was I replacing the cache drive but I was replacing it with a smaller drive.

 

500G Momentus - 128ssd.

 

Wondering if that contibuted to the parity problems?

 

 

Link to comment

I don't understand what you mean by "the guide at the bottom".

 

The procedure I pointed you to will work as expected if the amount of data you have on your original cache disk will fit on your smaller new one. I assume that is the case from what you say in the first sentence of your original post. Even if you had more data than would fit it wouldn't cause any problems - just that some of it would stay on the array instead of being moved back onto the new cache disk.

 

Wondering if that contibuted to the parity problems?

 

Cache disks are outside of the parity protected array so, no.

Link to comment

Turl - Moved 2nd Parity drive to Array. Operation success - perfect.

 

John_M. - The forum page has the procedure for "How do I replace/upgrade my single cache device? (unRAID v6.2 and above only)" but at the bottom of the page also has FAQ on Can I replace my cache device with a smaller one?

 

"The procedure I pointed you to will work as expected if the amount of data you have on your original cache disk will fit on your smaller new one." so as long as I follow:

 

    Stop all running Dockers/VMs

    Settings -> VM Manager: disable VMs and click apply

    Settings -> Docker: disable Docker and click apply

    Click on Shares and change to "Yes" all cache shares with "Use cache disk:" set to "Only" or "Prefer"

    Check that there's enough free space on the array and invoke the mover by clicking "Move Now" on the Main page

    When the mover finishes check that your cache is empty (any files on the cache root will not be moved as they are not part of any share)

    Stop array, replace cache device, assign it, start array and format new cache device (if needed), check that it's using the filesystem you want

    Click on Shares and change to "Prefer" all shares that you want moved back to cache

    On the Main page click "Move Now"

    When the mover finishes re-enable Docker and VMs

 

Can't thank you guys enough for the help... (spoon feeding).

 

Link to comment

Yes, that's what you need to do.

 

The post (#25 in that thread) at the bottom is really about replacing a disk in a cache pool, rather than a single cache disk. What you are about to do is to remove your cache disk and then replace it by first moving its contents temporarily to a safe place (the array) and afterwards moving it back. That other post is about manipulating the data within a cache pool. You don't have a cache pool - just a single cache disk - so it doesn't apply to you.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.