Drive showing reiserfs superblock cannot be found

As I've posted in another thread, I am trying to put together an ESXi unRAID build.  That's had it's share of problems, so I deiced to go ahead and get my unRAID server setup outside of ESXi.  I've been trying to troubleshoot a slow parity sync and when I powered it back on this last time, disk 12 was chalking up the erros while the parity sync was running.  I suspected a loose cable or something simple since it was fine and all the drives showed good SMART reports yesterday.  So I checked the cables and powered it back up and the drive is now showing as unformatted.  I just ran another short SMART test and the results look good so I ran reiserfsck and it returned:

 

reiserfs_open: the reiserfs superblock cannot be found on /dev/md12.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

 

How do I proceed from here?  Not sure what could've happened to the drive.

 

I am running 5 beta 12a.

What are the questions I need to answer correctly when I run --rebuild-sb?

After reading everything I could find about the --rebuild-sb, I felt confident enough to go ahead and try it.  According to the couple threads I could find I answered all the questions correctly, but it doesn't seemed to have worked.  After telling it yes to the final question it came back a split second later and said "The fs may still be unconsistent. Run reiserfsck --check.".  So I ran reiserfsck --check again, but it still says it can't find the superblock and says to run reiserfsck --rebuild-sb.  Here is the whole screen log:

 

Tower login: root
Linux 3.0.3-unRAID.
root@Tower:~# reiserfsck --rebuild-sb /dev/md12
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/md12.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:
4096

No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified).
Is journal default? (y/n)[y]: y

Did you use resizer(y/n)[n]: n
rebuild-sb: no uuid found, a new uuid was generated (df719e67-64dd-4232-828f-05e69d165b36)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x90c of format 3.6 with standard journal
Count of blocks on the device: 122096624
Number of bitmaps: 3727
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: df719e67-64dd-4232-828f-05e69d165b36
LABEL:
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Tue Sep  4 05:17:05 2012
Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@Tower:~# reiserfsck --check /dev/md12
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/md12
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/md12.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

root@Tower:~#

 

What do I do now???

 

 

Anyone?  I'm desperate to try and recover this disk.

Anyone?  I'm desperate to try and recover this disk.

have you rebooted?  It appears as if the "md" device is not connected to the /dev/sdX1 physical device?

 

If you have rebooted, you can attempt to run reiserfsck on the physical device.  This WILL NOT update parity, so that will have to be dealt with separately with a subsequent parity sync once all the data disks are online.

 

You have not attached a syslog for analysis, so I cannot offer any specific guidance.  Is the disk without the superblock partitioned correctly?  Is it > 2TB? or less ??

 

What happens when you type:

fdisk -lu /dev/sdX

and (if greater than 2TB)

gpart -l /dev/sdX

 

Does it show a partition exists?

If it does, and the partition starts on the expected sector, then you can try running reiserfsck on the sector itself to see if the superblock exists.  If the partition is NOT on the expected sector, then perhaps that is why the superblock is not found... it is looking in the wrong place.

 

You may have already clobbered the old superblock, but perhaps not....  Only way to know is first post a zipped syslog, then reboot.

 

Joe L.

 

I will attach a log when I get home tonight.  I assumed the output from reiserfsck was sufficient.  I will also run those commands and post the results. The drive ia 500GB and had been formatted and full of data for some time before this happened.

 

I have rebooted multiple times.  Since I was merging two servers together, I had no valid parity and was resyncing the parity when this occurred.  In the mean time I decided to remove the problem drive and resync parity on the remaining drives so the array wasn't unprotected.  So when I get home I'll stop the array, add the drive and run the check and commands.

I will attach a log when I get home tonight.  I assumed the output from reiserfsck was sufficient.  I will also run those commands and post the results. The drive ia 500GB and had been formatted and full of data for some time before this happened.

 

I have rebooted multiple times.  Since I was merging two servers together, I had no valid parity and was resyncing the parity when this occurred.  In the mean time I decided to remove the problem drive and resync parity on the remaining drives so the array wasn't unprotected.  So when I get home I'll stop the array, add the drive and run the check and commands.

In the process of merging, it is possible the drive had its MBR reset to point to the wrong starting sector.  Do you know if it was partitioned with a starting sector of 63, or of sector 64?  (Older unRAID versions only supported sector 63, 4.7 and newer allowed you to choose sector 64 to accommodate brain-damaged drives that performed poorly in some tests with small files when not accessed on a 4k alignment.)

I really can't say with any certainty which way it was partitioned.

I really can't say with any certainty which way it was partitioned.

OK, I need you to run this command and post the output.

 

dd if=/dev/sdX count=195 | od -c -A d |  sed  30q

 

(You'll need to substitute /dev/sdX with the actual physical device name for your disk)

 

As part of the output, you'll see something like this:

If the file-system actually starts on sector 63 you would see:

0097840 220  \0 002  \0  R  e  I  s  E  r  2  F  s  \0  \0  \0

 

If it starts on sector 64, you'll see it 512 bytes higher.

 

See this thread for more details when I assisted a different unRAID user. http://lime-technology.com/forum/index.php?topic=15385.0

I stopped the array and shut down the machine and added the problem drive back in.  I booted up and added the drive to the array and nothing else.  The syslog was captured at that point.

 

root@Tower:~# fdisk -lu /dev/sds

Disk /dev/sds: 500.1 GB, 500107862016 bytes
1 heads, 63 sectors/track, 15504336 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sds1              63   976773167   488386552+  83  Linux
Partition 1 does not end on cylinder boundary.

 

 

Tower login: root
Linux 3.0.3-unRAID.
root@Tower:~# dd if=/dev/sds count=195 | od -c -A d |  sed  30q
195+0 records in
195+0 records out
99840 bytes (100 kB) copied, 0.0203548 s, 4.9 MB/s
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000448  \0  \0 203  \0  \0  \0   ?  \0  \0  \0 361   _   8   :  \0  \0
0000464  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000496  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   U 252
0000512  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0097792 376  \v   G  \a 224 212   R  \0 327 024   K 001 022  \0  \0  \0
0097808  \0  \0  \0  \0  \0      \0  \0  \0 004  \0  \0 026   d   *   M
0097824 204 003  \0  \0 036  \0  \0  \0  \0  \0  \0  \0  \0 020 314 003
0097840   |  \0 002  \0   R   e   I   s   E   r   2   F   s  \0  \0  \0
0097856 003  \0  \0  \0 005  \0 217 016 002  \0  \0  \0 360 004  \0  \0
0097872 001  \0  \0  \0   T   A   S   $ 315  \r   I 360 227   @   w 245
0097888   C  \0 343 306  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0097904  \0  \0  \0  \0 225  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0097920  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0097984  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0
0098000   %  \0  \0  \0   (  \0  \0  \0 204  \0  \0  \0 206  \0  \0  \0
0098016 213  \0  \0  \0 214  \0  \0  \0 362  \0  \0  \0 363  \0  \0  \0
0098032 375  \0  \0  \0 376  \0  \0  \0 377  \0  \0  \0  \0 001  \0  \0
0098048 002 001  \0  \0 003 001  \0  \0  \v 001  \0  \0  \f 001  \0  \0
0098064 025 001  \0  \0 026 001  \0  \0 027 001  \0  \0 030 001  \0  \0
0098080   ! 001  \0  \0   " 001  \0  \0   # 001  \0  \0   $ 001  \0  \0
0098096   . 001  \0  \0   / 001  \0  \0 266 001  \0  \0 267 001  \0  \0
0098112   9 002  \0  \0   : 002  \0  \0 337 002  \0  \0 340 002  \0  \0
0098128 025 003  \0  \0 026 003  \0  \0   < 003  \0  \0   = 003  \0  \0
0098144   | 003  \0  \0   } 003  \0  \0 207 003  \0  \0 210 003  \0  \0
0098160 231 003  \0  \0 232 003  \0  \0 277 003  \0  \0 300 003  \0  \0

syslog.txt

Does any of that help?

Does any of that help?

Well, it looks as if the disk is partitioned to start on sector63, and the reiserfs starts there too.

 

You can try

reiserfsck --check /dev/sds1

 

Be aware though, that if you run any reiserfsck command on the /dev/sds1 device that repairs the disk, that parity will no longer be correct.

 

Joe L.

OK I tried that which (using sdt1 instead since that is what the drive is now assigned), of course, still complains about the superblock,  So I ran the --rebuild and when it finished, I ran a --check.  That returns "Bad root block 0. (--rebuild-tree did not complete)".

 

Here is the whole screen log:

 

root@WOPR:~# reiserfsck --check /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/sdt1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdt1.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

root@WOPR:~# reiserfsck --rebuild-sb /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdt1.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, ch                                                                                                                     oose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:
4096

No journal device was specified. (If journal is not available, re-run with --no-                                                                                                                     journal-available option specified).
Is journal default? (y/n)[y]: y

Did you use resizer(y/n)[n]: n
rebuild-sb: no uuid found, a new uuid was generated (96a8d67e-755d-4702-a964-0f5                                                                                                                     df171320f)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x4131 of format 3.6 with standard journal
Count of blocks on the device: 122096624
Number of bitmaps: 3727
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks):                                                                                                                      0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: 96a8d67e-755d-4702-a964-0f5df171320f
LABEL:
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Sun Sep  9 17:50:10 2012
Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@WOPR:~# reiserfsck --check /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/sdt1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Sun Sep  9 17:51:21 2012
###########
Replaying journal: No transactions found
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted
root@WOPR:~#

 

 

After a Google search, I found a site that if you get that message you should run:

 

# reiserfsck --scan-whole-partition --rebuild-tree /dev/sda1

 

Is that the right thing to do?

OK I tried that which (using sdt1 instead since that is what the drive is now assigned), of course, still complains about the superblock,  So I ran the --rebuild and when it finished, I ran a --check.  That returns "Bad root block 0. (--rebuild-tree did not complete)".

 

Here is the whole screen log:

 

root@WOPR:~# reiserfsck --check /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/sdt1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdt1.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

root@WOPR:~# reiserfsck --rebuild-sb /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdt1.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, ch                                                                                                                     oose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:
4096

No journal device was specified. (If journal is not available, re-run with --no-                                                                                                                     journal-available option specified).
Is journal default? (y/n)[y]: y

Did you use resizer(y/n)[n]: n
rebuild-sb: no uuid found, a new uuid was generated (96a8d67e-755d-4702-a964-0f5                                                                                                                     df171320f)

rebuild-sb: You either have a corrupted journal or have just changed
the start of the partition with some partition table editor. If you are
sure that the start of the partition is ok, rebuild the journal header.
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x4131 of format 3.6 with standard journal
Count of blocks on the device: 122096624
Number of bitmaps: 3727
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks):                                                                                                                      0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: not set
Objectid map size 0, max 972
Journal parameters:
        Device [0x0]
        Magic [0x0]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: 96a8d67e-755d-4702-a964-0f5df171320f
LABEL:
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Sun Sep  9 17:50:10 2012
Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@WOPR:~# reiserfsck --check /dev/sdt1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to [email protected], **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/sdt1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Sun Sep  9 17:51:21 2012
###########
Replaying journal: No transactions found
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted
root@WOPR:~#

 

 

After a Google search, I found a site that if you get that message you should run:

 

# reiserfsck --scan-whole-partition --rebuild-tree /dev/sda1

 

Is that the right thing to do?

no, that is NOT the correct thing to do for a missing superblock. That would be IF it suggested a --rebuild-tree AND you wanted to try to recover/restore files you had deleted recently as best it could.  (those that had not been subsequently overwritten)

 

It may work in this case, since you've written a superblock to where you think it should have been.

You said to run --chech on the disk again. I did. As expected it returned the same message as before about the superblock and then said to run a --rebuild, which I did. Was that wrong? Is the best course of action to go ahead and run

--scan-whole-partition --rebuild-tree /dev/sdt1?

I have to send my mobo back for a replacement tomorrow so I would really like to try to fix the drive tonight while I can if possible.  Can anybody tell me if running the command below is the best thing to do next?:

 

# reiserfsck --scan-whole-partition --rebuild-tree /dev/sdt1

I have to send my mobo back for a replacement tomorrow so I would really like to try to fix the drive tonight while I can if possible.  Can anybody tell me if running the command below is the best thing to do next?:

 

# reiserfsck --scan-whole-partition --rebuild-tree /dev/sdt1

As I said, you can give it a try.  It may work, it may just abort.  You'll soon see.

It is basing its recovery on the superblock you apparently wrote in an earlier reiserfsck command.  That was created where your MBR partition pointed.

 

If the MBR was correct, all should be fine.  If the MBR pointed to the wrong sector, everything is a complete unknown, as you created the superblock in the wrong place.  There is an outstanding BUG in the 4.7 release that will cause it to potentially incorrectly write the MBR of disks based (I think) on the current default set in the unRAD settings when the existing super.dat file is missing (as when switching USB drives, or when re-loading one from scratch, or when you accidentally, or purposely,  remove the config/super.dat file).  several people have reported it to lime-technologies, no fix has been offered.

 

You'll soon see if your earlier command to rebuild the superblock was correct, or not.

 

Joe L.

But it won't do any harm?  At worst it just aborts, right?  If it aborts is there anything else to be tried or is that it and my data is just lost?

But it won't do any harm?  At worst it just aborts, right?  If it aborts is there anything else to be tried or is that it and my data is just lost?

You can potentially use a third-party tool to recover files, or re-format the drive and then use the --scan-whole-partition option to try to recover files.  You could even try to set the partition to sector 64 and try re-formatting/scanning for files there. 

 

All of this is FAR better done on a copy of the data, but you are way past that, in that you've already written and modified the superblock and MBR that was on the disk.  (Best you could do is work on a copy that would let you get back to exactly where you are right now, so you could try a different approach)

Thanks. I'll try it that command when I get home.  I would love to know how the heck this happened.  A simple parity sync started showing a bunch of errors on the drive (multiple every second).  I cancelled the parity sync, stopped the array, powered down, checked cables, rebooted and then unRAID tells me the drive needs formatted.  Nothing should have happened to this drive.

OK.  That procedure finished with results and didn't seem to abort.  Unfortunately, the screen only showed a few of the results and in trying to go back for more, I ran cat /var/log/syslog and nothing shows in the log.  Now there is nothing on the screen pertaining to running that command for me to post here. How do I check the contents of that drive now.  I can't seem to figure that out.  I'm afraid to start the array as its showing the drive as new and I'm afraid it might just start clearing it.

I finally figured out that you can mount the drive outside the array with unMENU.  I enabled that and I see a bunch of files and directories and it looks to be my movies.  I then clicked enabled sharing of the drive via unMENU so I can view them in Windows and see if the play OK or not.  But when I try to access the drive inWindows it asks for my username and password.  Shares never normally do that.  I entered the username and password I have setup in unRAID, but it says access denied.  Do I need to change something to get the proper permissions?

Thanks a lot Joe!  You were a big help.  I finally managed to figure out that I had to change permissions to be able to access the share.  It turns out that the drive had 96 DVD movies on it and all were fine except for 11.  When I tried playing them, they wouldn't play all the way through.  Not tooooo bad but it was a lot of painstaking "click and try" to figure out what was in all the arbitrarily named files and folders.  In the end it sure beats the heck out or re-ripping an additional 85 movies.

 

I still don't understand what the heck happened and why I had any corrupted files, but it is what it is I guess.