Today I wanted to upgrade from 4.7 to 5.0rc8a for the purpose of installing 3TB drives.

 

Before proceeding the upgrade i've disabled parity since this was a 2TB drive and would have to be replaced first.

When adding the 3TB seagate drive, the problems started.

After about 10 minutes of starting my array, the seagete drive suddenly disapaered and so the arry was invalid and stopped.

I'v retried several times of adding the 3TB drive but without succes after a while it waas rejected.

So I decided to withdraw the seagate drive and restarted my array with my initial drives.

 

I've wanted to copy some data of one of my drives to another one in my array and suddenly started to get reiserfs I/O errors on a disk which haven't had errors before (write potected disk).

 

After several reboots the result stayd the same, impossible to copy any data of the drive.

I ran reiserfsck --check and it did not find a valid  reiserfilesystem on the drive (when mounted all directory's and files appear to be present).

I ran reiserfsck --rebuild-sb and afterwards reran reiserfsck --check which now ouptut in short the following error:

Bad block 0, aborted

 

Should I run reiserfsck --rebuild-tree, or I'm I going to lose all my data that way.

 

The strange thing is when mounted all my files and directory's seem to be present, but I can't read any of them (write protection error).

 

 

 

I've been checking all my drives with the reiserfsck utilty and I get the same error report for all my drives (which are 12 in total by the way):

 

"The reiserfs superblock cannot be found, failed to open filessytem."

 

Is this normal, or have I corrupted my whole filesystem here by doing the upgrade ?

 

 

 

I've been checking all my drives with the reiserfsck utilty and I get the same error report for all my drives (which are 12 in total by the way):

 

"The reiserfs superblock cannot be found, failed to open filessytem."

 

Is this normal, or have I corrupted my whole filesystem here by doing the upgrade ?

Are you running the command on the partition on the disk? or the disk device itself?  The former is correct, the latter incorrect, it will never be found there.

 

Perhaps you can give the full EXACT commands you are using.

 

I see you've already written to one of the disks in an attempt to rebuild a superblock.  What EXACT command did you use?

 

Was it on

  /dev/sdX1

or

/dev/sdX

or

/dev/mdX

 

 

Do NOT do any more re-construction on the file system until you are sure you are pointing to the right partition.  (You are only causing damage by doing so)

 

Joe L.

The command that I ran was the reiserfsck --check /dev/sdX on all my drives (from the server command line)

 

I'v tried the rebuild only on the drive from which I can't copy any file anymore.

On that specific drive I get an I/O error when trying to copy anything from it. The drive even get's kicked out of the array when doing so.

 

Strangely enough I don't get any fault messages in teh webinterface (no read errors).

The command that I ran was the reiserfsck --check /dev/sdX on all my drives (from the server command line)

And, unfortunately, that is wrong.

You want to check the file system on the partition, not on the base drive.  It is why the superblock could not be found. (you pointed it to the wrong spot)

 

You ALWAYS want /dev/sdX1  That is the first partition on the disk if you are checking the raw disk without parity involved.  The reiser file system resides on the first partition.    Now, there is an issue running the check there.  If you change anything, it is NOT reflected in parity.  To have parity in sync, you instead need to run the reiserfsck on the /dev/mdX device.  md1 = disk1, md2 = disk2, md12 = disk12, etc.

Those "md" devices are logically connected/associated with the first partition on their affiliated disks when you use the "assignment" page on unRAID.  If you run

reiserfsck --check /dev/md9

you will check disk9.  If you run

reiserfsck --fix-fixable /dev/md9

then the fixes are applied to the partition AND to parity.

 

If you run the --rebuild-sb on the /dev/sdX device, you've just possibly clobbered part of the partition table and possibly overwritten the initial part of the first partition.  (in other words, shot yourself in the foot by pointing the gun at your foot instead of the target before pulling the trigger)

I'v tried the rebuild only on the drive from which I can't copy any file anymore.

On that specific drive I get an I/O error when trying to copy anything from it. The drive even get's kicked out of the array when doing so.

 

Strangely enough I don't get any fault messages in teh webinterface (no read errors).

You can have a corrupted file system and still have everything be readable.  The two really are not related. (although if part of the file-system is not readable, it might lead to corruption)

 

You might have gotten lucky if the disk had actually died.    The unable to read block 0 might have saved you some grief.

 

Going forward, do all your reiserfsck on the /dev/mdX devices as described in the wiki:

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

 

Joe L.

Thx Joe,

 

I've retested the drives as you proposed.

All drives seem to test OK, with one exeption, that's the drive from which I couldn't copy any file after migration.

(also the drive on which I performed the faulty reiserfsck repair afterwards)

 

I get the following error message running reiserfsck --check:

 

0 transactions replayed

cannot read block 2700467072 (input output error).

 

What I would like to do now is to recover the data on that drive.

Parity rebuilding the drive isn't an option. When I migrated yesterday, I've removed the 2TB parity drive and wanted to replace it with a new 3TB drive , and afterwards just rebuild the parity drive from scratch.

So for now there's no parity drive installed.

 

Since I would like to recover the data, should I try doing so with reiserfsck ?

Or should I try manually:

-remove the drive from array, proceed with a new array build and parity rebuild with the remaining disks, and afterwards to recover data with winhex on the removed drive  for example ?