[SOLVED] reiserfsck -rebuild-tree suggested by reiserfsck


kricker

Recommended Posts

I notice an issue where I could not move/delete some files on the unRaid system. I found out that they are mounted as read only. There seems to have been some sort of reiser issue causing things to be mounted as read only. I followed the instruction to run a reiserfsck and the results are attached below. Syslog also attached.

 

http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later

 

The above page mentions to not run the --rebuild-tree option without some expert consultation, so that is why I am here. What is my next step?

reiserfsck.jpg.d2d976b48bc3e819f47ac4b82e2af0c1.jpg

syslog.zip

Link to comment

The above page mentions to not run the --rebuild-tree option without some expert consultation, so that is why I am here. What is my next step?

 

Yeah, portions of that page were written many years ago, including those warnings in red!  I think it's time to relax them, turn off the red, especially now with the webGUI to run the command.  At the same time, there was a reason it was in red.  We didn't want people just casually running those options, without knowing how dangerous they were.  It's like heart surgery, you don't ask for it unless you really need it.  It never returns the system to perfect, and there may be a little data loss.  It does a great job, and makes the drive usable again, but it's possible files may be lost or corrupted, or moved into the lost+found folder.

 

Go ahead and rerun the reiserfsck command with the --rebuild-tree option.  Unfortunately if it says you need it, then you do.

 

Was there any reason you preferred the command line over the webGui method?  If you like, you can use the webGUI method and put the --rebuild-tree option into the options box, and click the Check button.

Link to comment

I didn't even realize I could do it from the GUI now. I'll have to look and get familiar with that. I did run the command and it finished. There was nothing in the lost & found folder. Whatever was corrupt is just gone, and I have no clue what it may have been.

 

This issue has brought up some questions though. What is md1? The drives are sda, sdb, etc. I have never seen a md1 drive. Was this an issue with a single drive or is it something that is spread across devices?

Link to comment

The sda, sdb, etc are the names of the disk devices, with sda1, sdb1, etc being the 1st partition on those disks.  When you use these names any writes are made to those disks/partitions only.  The order the physical disks are assigned to which name is determined by the order the disks respond during boot time, so can vary depending on each boot.

 

The md1, md2, etc are similar to the sda1, sdb1, etc partition names except the names are allocated according to which disk has been allocated to which unraid disk slot (so are consistent across system boots).  But most importantly, any write to these md devices not only update the physical disk partition but also the parity disk.

 

Therefore if you run reiserfsck on the sda1, sdb1 devices and it makes a change on the disk but not parity, your parity disk is now invalid for wherever the write was done

 

However if you run reiserfsck on the md1, md2, etc devices and a change is made to the disk then the parity is also updated thus ensuring that the parity disk remain valid.

Link to comment

I didn't even realize I could do it from the GUI now. I'll have to look and get familiar with that. I did run the command it it finished. There was nothing in the lost & found folder. Whatever was corrupt is just gone, and I have no clue what it may have been.

It should be fixed then, hopefully with nothing lost.

 

This issue has brought up some questions though. What is md1? The drives are sda, sdb, etc. I have never seen a md1 drive. Was this an issue with a single drive or is it something that is spread across devices?

What he said above.  Just run a correcting parity check, and let it do whatever correcting it needs to.

Link to comment

So I should run a parity now after the rebuild-tree has finished?

 

If there is an issue with md1, is it possible to pull the drive and replace it with a new one and have it rebuild from parity and the reiser issue I had originally get fixed and not risk loosing anything with the rebuild-tree command? Or can a reiser issue like that actually get stored in the parity as well?

Link to comment

It would certainly be a good idea to run a parity check to ensure that your parity is still correct.

 

Certainly you could do what you suggest but I suspect that your rebuilt disk would just recreate the original file system corruption.

 

The problem is that we don't know what caused the original file system corruption that made the system put the disk into read only mode.  There is some debate about when you should trust your data disks or your parity when there is a discrepancy ..... But the general consensus appers to be that in the absence of other evidence you should trust your data and correct your parity.

 

Whatever the case it is important to ensure that the data disks and parity agree to ensure correct operation in the future.

Link to comment
  • 5 years later...

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.