Hello,

 

I attempted to recover some files yesterday on one of my disks, disk6. I started with this post: http://lime-technology.com/forum/index.php?topic=5087.msg47070#msg47070, and ran reiserfsck --rebuild-tree -S /dev/md6. Shortly after starting the rebuild, I decided that it wasn't worth waiting 30,000 seconds (20+ days) to possibly recover my FireFox profile, so I aborted the procedure with CTRL-C. Then, I began a data rebuild on the disk. 8 hours or so later, it seemed to have completed successfully- but the disk was "unformatted". I'd thought I could just replace a "failed" disk, but thinking that I'd forgotten to format it, I did so, and then re-ran the data rebuild. Now it's completed again... I have 3TB free on a 3TB disk. Valid parity. The disk is showing 12658368 writes to it, 0 errors, but the user share that was on that disk (and only on that disk) is gone. I am not sure what else to do at this point? syslog attached.

 

If anyone has any ideas, I would really appreciate it.

 

~Sean

syslog.zip

Now I am wondering if I should go buy another disk and try to rebuild THAT one? I don't know. I just kind of need the data on it. I DO have valid parity, so I'd think it would just be a matter of rebuilding.

Parity reflects the drive in its current state. The recover the data you'll need to use reiserfsck or another data recover program.

Thanks. I haven't done a parity rebuild since this happened, however. In other words, it's as if the drive simply failed. As far as I am aware, the parity drive <i>should</i> contain the data that is no longer on the drive, should it not?

Running reiserfsck --rebuild-tree on /dev/md6 updates parity.

Wait - umounting my md6 disk and running that command updates my PARITY disk?

 

This is what I did (from the other post I linked to)

 

stop samba  [all your shares will disappear from network]

killall smbd nmbd

 

un-mount the disk  (md1=disk1, md2=disk2, md10-disk10,  etc.  Use the correct disk for your needs. this example is for disk1)

umount /dev/md1

note the above command is umount, not unmount.

 

run reiserfsck on the disk to rebuild the file tree.  Any files that can be recovered will.  This process could take many hours for a large disk as the entire disk will need to be scanned.

reiserfsck --rebuild-tree -S /dev/md1

 

It will ask you to confirm the rebuild of the file tree. Make certain you answer Yes (three letters, Capital "Y", lower case "es")

Anything else will be considered as "no"

 

re-mount the disk  (again, use the correct "md" and "disk" for your situation)

mount /dev/md1 /mnt/disk1

 

re-start samba

/usr/sbin/smbd -D

/usr/sbin/nmbd -D

 

your deleted files (any that could be recovered) will be in a lost+found folder on the disk.

 

Now - I interrupted the process, and simply did a data rebuild. well, then a format, then ANOTHER rebuild on md6.

Yes. Operations on md6 modify parity. To recover the data you'll need to use reiserfsck or another data recover program.

Ok. thanks. Still doesn't make all that much sense to me - I'd thought I was only modifying md6. I guess if this should ever happen again, I will physically remove the drive and attempt a recovery operation on the data elsewhere, so that the parity drive is no where near it.

Ok - now after running reiserfsck --rebuild-tree -S /dev/md6, I see this:

 

vpf-10680: The file [285877 286832] has the wrong block count in the StatData (40) - corrected to (0)

vpf-10680: The file [285877 286856] has the wrong block count in the StatData (32) - corrected to (0)

vpf-10680: The file [285877 286956] has the wrong block count in the StatData (16) - corrected to (0)

vpf-10680: The file [285877 286964] has the wrong block count in the StatData (16) - corrected to (0)

vpf-10680: The file [285877 286992] has the wrong block count in the StatData ( - corrected to (0)

vpf-10680: The file [285877 287004] has the wrong block count in the StatData (16) - corrected to (0)

lost+found.c 348 pass_3a_look_for_lost

look_for_lost: The entry 'lost+found' could not be found in the root directory.

Aborted

root@Tower:/mnt# mount /dev/md6 /mnt/disk6                                                                                                           

mount: /dev/md6: can't read superblock

 

Any idea what I should do at this point?

 

Thank you,

 

Sean

I'm wondering if I should just give up and call it a loss at this point.

Well - I am going to try to rebuild the superblock, in the hopes that that lets me recover SOMETHING. And I have purchased another 3TB drive, so I can install that one in place of the one I have been trying to recover files from. Maybe I can do a data rebuild on it.