Hello.  I recently replaced a defective drive, and just finished restoring the array.  Now, whenever I want to write something to the drive, it says "you need permission to perform this action."  I can read from it though.  Kindly help.

See check disk filesystems in my sig.

Thanks.  Output says rebuild --tree. 

That is ok. Repeat reiserfsck with --rebuild-tree.

ok, let's see what happens.  Will report back.

Hello dgaschk, do you think there's a possibility there's no problem with filesystem, instead, it's write-protected?  Saw this message when I started --rebuild-tree

 

"Filesystem seems mounted read-only"

 

Will await your reply.  Thanks

Hello dgaschk, do you think there's a possibility there's no problem with filesystem, instead, it's write-protected?  Saw this message when I started --rebuild-tree

 

"Filesystem seems mounted read-only"

 

Will await your reply.  Thanks

Did you stop the array, and put it into Maintenance mode?    You cannot run the reiserfsck against the array with the drives mounted.

Hello dgaschk, do you think there's a possibility there's no problem with filesystem, instead, it's write-protected?  Saw this message when I started --rebuild-tree

 

"Filesystem seems mounted read-only"

 

Will await your reply.  Thanks

 

See Check Disk Filesystems in my sig. Read the instructions completely and follow them carefully. Carelessness with reiserfsck will completely destroy the file system.

UnRAID main shows the device label for the cache drive.

 

cache /mnt/cache	ST32000542AS_5XW17SMK (sdf) 1953514552

 

In this example, /dev/sdf1 is used instead of /dev/md#. Find the correct value on your system. Do not forget the trailing number 1.

Shouldn't you do it on the MD device to keep parity in sync?

The cache drive in not parity protected.

missed that this was the cache drive. 

How was it decided this was the cache drive?

 

I recently replaced a defective drive, and just finished restoring the array.

 

Sounds like an array disk to me.

 

The read-only will require stopping and starting the array. If it still doesn't mount as read/write allowing you to fix it via the /dev/mdX device then you'll have to check the raw device /dev/sdX1.

 

*X = the variable matching the drive in question. md1, md2, md3, sda1, sdb1 etc...

 

It you use the /dev/sdX1 device on an array disk then you are breaking parity and you have to do a parity check once you are done.

 

you're right, the OP said that no where.

 

 

@OP, post a syslog.

The OP sent me a PM asking about checking the cache drive.

Hello All,

 

Sorry for causing the confusion.  Indeed it's an array drive, not a cache nor parity drive.  I followed dgaschk's advice and stopped the array and went to maintenance mode (as I forgot to do it).  When I left the device performing reiserfsck with --rebuild-tree, when I came back, my terminal putty wasn't around anymore.  Don't know what happened. 

 

I have a question though.  I thought replacing a defective drive is as simple as stopping the array, replace defective drive with a new one, select the new drive as the newly assigned disk, then start array.  How come I have this problem of read only?  Somehow, I also have this feeling that if I access more files from the drive, more problems will come out. 

 

Is there also anyway for me to just remove the newly replaced drive, then format it once again, then put it back in?  This way, it will once again use the disk1 and parity to rebuild data of disk2 (newly replaced drive).

 

Can someone please share their thoughts? 

 

 

If you have a corrupt file system on a disk, then replacing the disk does not fix the issue as it is rebuilt with the same corruption that was present before the disk failed.  It is the running of the reiserfsck command with appropriate correction options that fixes the file system corruption.

itimpi, thanks for clarifying things.  Would you know why a perfectly working array will get corrupted filesystem when parity and disk1 are both functioning well?  They alone should be able to reconstruct data for disk2 right?

itimpi, thanks for clarifying things.  Would you know why a perfectly working array will get corrupted filesystem when parity and disk1 are both functioning well?  They alone should be able to reconstruct data for disk2 right?

All sorts of things can cause this such as a power blip or a software fault to a cosmic ray changing data.  If reading a sector appears to complete without error then no attempt is made to read the other disks and parity to check that they agree with the sector read.  If this happens on a disk sector containing file system information it can lead to such corruption (as opposed to the case where it is a sector in a file that affects just that file). 

 

One of the good things about using reiserfs is that there is enough information stored that the tools can normally recover from this. 

 

This is also the reason for carrying out periodic parity checks to confirm that data does not appear to have changed since it was written.

 

It is also the reason why you will see threads talking about using checksum tools to ensure that this type of silent 'bit-rot' has not taken place.