[SOLVED] Repeated problem: some shares read-only fsck errors


Recommended Posts

I am using Unraid for over 2.5 years. Now I have Version 4.7 with 11 Hard disks 2TB and 1.5TB and 1 cache 2TB

I am facing the following problem recently (last 2 months) and and not only once

The problem starts when trying to copy something to a disk share sometimes stops writing and seems that the disk is in read only mode.

then if I run reiserfsck --check seems that the problem is fixed.

 

Today though is a different story.

Again I couldn't write on one of my disks (WD20EVDS)

I ran reiserfsck --check and found too many errors,

then I ran reiserfsck --fix-fixable which fixed all errors but one

I rerun reiserfsck --fix-fixable to make sure and the result is attached in file fsck-fix-fixable.txt

 

Another thing I noticed is that I cannot run long smart test on this drive, always I got the message aborted by host (from the first seconds of the test)

 

The question is shall I proceed to --rebuild-tree as fsck recommends or shall I do something else first...

 

Thank you in Advance

 

P.S. It's only 11 days since the last parity check.

fsck-fix-fixable.txt

syslog.txt

smart-report.txt

Link to comment

I am using Unraid for over 2.5 years. Now I have Version 4.7 with 11 Hard disks 2TB and 1.5TB and 1 cache 2TB

I am facing the following problem recently (last 2 months) and and not only once

The problem starts when trying to copy something to a disk share sometimes stops writing and seems that the disk is in read only mode.

then if I run reiserfsck --check seems that the problem is fixed.

 

Today though is a different story.

Again I couldn't write on one of my disks (WD20EVDS)

I ran reiserfsck --check and found too many errors,

then I ran reiserfsck --fix-fixable which fixed all errors but one

I rerun reiserfsck --fix-fixable to make sure and the result is attached in file fsck-fix-fixable.txt

 

Another thing I noticed is that I cannot run long smart test on this drive, always I got the message aborted by host (from the first seconds of the test)

 

The question is shall I proceed to --rebuild-tree as fsck recommends or shall I do something else first...

 

Thank you in Advance

 

P.S. It's only 11 days since the last parity check.

 

--check never fixes anything.  It only reports on errors which might exist.

If --fix-fixable reports that you need to run --rebuild-tree, then you MUST run --rebuild-tree to fix the error.  That is how you must proceed.

 

The "Long" smart test take 4 hours or more.  If you have the disks spinning down by unRAID, the spin-down will abort the test, aborted by a command from you to spin down the disk.  If you wish to perform a long test, you must disable spin-down.

 

Joe L.

Link to comment

Thank you for your fast response! :D

I am running now reiserfsck --rebuild-tree...

see what will happen...

 

I already know about the spinning down issue with smartctl long test (I have run numerous tests with smartctl) and I had already disabled the spinning down of the disk I wanted to check. Anyway I don't think this is a big issue.

 

Thank you again.

Link to comment

I just wanted to share the results

The rebuild-tree finished,

fixed all issues, But it altered some of my files...

I keep MD5 for all of my files, so after the rebuilt-tree finished, I had around 10 files with different MD5 than the original...

 

This wasn't big issue in my case because I did a backup of the harddisk before the reiserfsck command...

So in conclusion I believe it's better to do a backup first before running reiserfsck with the rebuilt tree switch...

 

Link to comment
  • 1 month later...

I'm going through this exact same situation right now with a few months old Hitachi 2TB disk12. I just precleared another disk since my disk3 is failing according to a SMART test. I'm now wondering whether I should use the precleared drive to back up the read-only disk12 before running reiserfsck in anything other than --check mode?

 

--check (still running) says that

The level of the node (0) is not correct, (1) expected

the problem in the internal node occured (143196162), whole subtree is skipped.

This is being repeated for several other (xxxxxxxxx) values.

Link to comment

As I said in the previous post It's always better to make a backup first before running any other fsck command

because in my case some files were altered after the rebuild-tree.

anyway good luck, Hope not to have too many files to transfer,

and after the backup, see what reiserfsck recommends (probably --rebuild-tree)

and keep an eye on this hard disk. maybe a long smart test or something.

I changed mine after a while because it got some reallocated sectors.

 

Good luck,

Nick

Link to comment

Thanks, Nick.

I'm slowly but surely copying the important media off the drive first. I have almost 2 TB of it. Unfortunately the disks with significant space on them are numbered higher than 12. So when there are duplicates, unRAID tends to use the lowest numbered drive that has a copy of the file.

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.