I have 10 disks in my array.  1 for parity (obviously), and 9 data disks.  everything has been working well for a long time now but the other day i noticed that suddenly disk 9 reports that it is unformatted.  I don't know how to tell exactly what data is stored on there, but i know that disk 9 is included in a few of my shares and i don't seem to be missing any data... why would unraid suddenly report that it is unformatted?

Whatever you do, do NOT format the drive by pressing the "format" button.

 

Usually, a disk ends up showing as "unformatted" when you attempt to stop the array.  Usually it is multiple disks, but it can  be just one.

To unRAID, a disk that is unformatted was one that could not be mounted as a valid reiserfs file-system.  It could be because it was corrupted, or it could be because it already was mounted, and could not be mounted again a second time.

 

See the FAQ in the wiki:

http://lime-technology.com/wiki/index.php/FAQ#Why_is_a_disk_showing_as_Unformatted.3F

 

Are you running any add-on scripts, or was the "mover" script moving a file from cache to a data disk when you attempted to stop the array?

 

SO... to help us to understand the situation, before you do anything at all, post a copy of your system log.  Do not re-format the un-formatted disk, do NOT press "Restore" as it would erase all knowledge of what used to be on the unformatted drive unless done in a very special sequence of actions.  Restore does not restore data, it is very poorly named.  It resets the array to before any parity calcs were done. 

 

Post the syslog.  Tell us when you saw the un-formatted display... Was it after you attempted to stop the array? Or at a different time?

 

To see what is on disk 9, just type this command:

find /mnt/disk9 -print

thanks for getting back to me - i just noticed your reply.  for some reason i never got the email notification from the forum.

 

so i have tried rebooting the server several times and that doesn't help.  it always comes back up with disk 9 unformatted.

 

so how do I go about getting the syslog so i can post it?

 

i don't recall a specific action which caused the disk to say it was unformatted.  but it has been that way for several weeks now.

 

i have been stopping and starting the array a lot because for some reason windows 7 will randomly lose connection to the array and the only solution is to stop and start the array.

thanks for getting back to me - i just noticed your reply.  for some reason i never got the email notification from the forum.

 

so i have tried rebooting the server several times and that doesn't help.  it always comes back up with disk 9 unformatted.

 

so how do I go about getting the syslog so i can post it?

instructions are in the wiki: http://lime-technology.com/wiki/index.php/Troubleshooting#Capturing_your_syslog

i don't recall a specific action which caused the disk to say it was unformatted.  but it has been that way for several weeks now.

 

i have been stopping and starting the array a lot because for some reason windows 7 will randomly lose connection to the array and the only solution is to stop and start the array.

Odds are the file-system on that drive is corrupted, and unable to be mounted.   We'll know for sure when you post the system log.

Please note that if using a registered version of unRAID (and you are if you have more than 3 disks) that your registered name is in the system log.

Use an editor to blank it out before posting it...  In the same way, you might scan through it for any other personal information... in most cases, they too can be blanked out.

 

On the most recent beta releases, the registered name was replaced by the registered GUID of the flash drive to protect privacy... but I don't know what version of unRAID you are running.

 

If the disk is simply not able to be mounted, you will need to go through the process of doing a file-system check on it.  That process is described in the wiki: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems

 

Joe L.

thanks - i will work on getting that filer and posting it.

 

and if it makes any difference i am using version 4.4.2

 

 

ok i have my syslog file.  i don't see any personal info in it but then i am not 100% sure what I am looking at.  would it be ok if i sent it to you outside the forum (direct message or email)?

 

then if you see any personal info feel free to strip it out and then post it here.  i just don't really know what I am looking at.

 

Search in the syslog for "registered to"

 

Joe L.

thank you.  so here is my syslog(attached)

 

 

thank you.  so here is my syslog(attached)

 

The important line was this:

Aug 13 08:10:07 StorageTower kernel: ReiserFS: md9: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on md9

You will need to run the reiserfsck program as described in the wiki on /dev/md9

 

You will not need to stop samba, or to un-mount it, because it was never mounted, so it can't be busy from a process accessing its files.

 

Therefore, the command you will need to run is:

reiserfsck /dev/md9

[answer with the word Yes when prompted, do not type yes or YES, but Yes (capital Y and lower case es)]

 

It might ask you to re-run it with the --fix-fixable option

reiserfsck --fix-fixable /dev/md9

... or

 

If it complains it is unable to find a reiserfs on the device, then you will need to rebuild the file-system superblock with the --rebuild-sb option.  The wiki has pointers to how, and you will be presented with a series of prompts.  At least one of the responses is not the default, so follow the thread where the example set of prompts was illustrated.

reiserfsck --rebuild-sb /dev/md9

 

Remember, follow the instructions in the output of the reiserfsck command.  Do NOT re-run a command... if you have already run a fix-fixable, or rebuild-sb, do not re-run it a second time without starting back with a basic check of reiserfsck /dev/md9 and again following its advice.

If it suggests re-running --fix-fixable AFTER you've rebuilt the suberblock with --rebuild-sb, then that is the correct thing to do.

 

Also, I'm sending you a PM. Look for it.

 

Joe L.

ok so i ran reiserfsck and it said the following:

 

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

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.

 

so i am nervous about running this because it apparently equires very precise answers to its prompts.

 

i am looking at the following (referenced in the wiki) and want to be double sure that these are the correct responses.  also how long should expect the process to take?  shoudl i take down the array first?  will the array be accessible while this process is running?

 

http://lime-technology.com/forum/index.php?topic=1483

so i am nervous about running this because it apparently equires very precise answers to its prompts.

 

i am looking at the following (referenced in the wiki) and want to be double sure that these are the correct responses.  also how long should expect the process to take?  shoudl i take down the array first?  will the array be accessible while this process is running?

 

http://lime-technology.com/forum/index.php?topic=1483

That is the correct set of responses.

No don't take down the array, you must leave the array up for the md9 device to be available.

 

Yes, the array will still be accessible while it runs.  Rebuilding the superblock with --rebuild-sb should only take a few seconds.

 

It appears as if there are two non-default prompts... the first and the last. 

 

Joe L.

Ok so i just ran it and used all the responses from that post.  it seemed to go ok.  so what is my next step?  do i run reiserfsck again with no flags to check the file system?  or so i just stop and start the array to see if drive 9 shows as formatted?

 

actually nevermind - i just noticed that it told me to run reiserfsck --check so i did that and it said the following:

 

Will read-only check consistency of the filesystem on /dev/md9

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 Thu Aug 13 10:57:12 2009

###########

Replaying journal..

Reiserfs journal '/dev/md9' in blocks [18..8211]: 0 transactions replayed

Checking internal tree..

 

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

 

Aborted

actually nevermind - i just noticed that it told me to run reiserfsck --check so i did that and it said the following:

 

Will read-only check consistency of the filesystem on /dev/md9

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 Thu Aug 13 10:57:12 2009

###########

Replaying journal..

Reiserfs journal '/dev/md9' in blocks [18..8211]: 0 transactions replayed

Checking internal tree..

 

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

 

Aborted

Yup.. you'll next need to rebuild the file-system tree.  This can take hours for a large disk.

reiserfsck --scan-whole-partition --rebuild-tree /dev/md9

 

Again, answer "Yes" when prompted, with a capital "Y" and lower case "es")

 

When it is done, go to the management console, stop the array, and then re-start it.  You should them be able to see how it did.  With any luck, your disk will not show as un-mounted.   Oh yes, files on that disk you recently deleted, but were not overwritten will be restored.  You can delete them again once you look to see your other files are back.

 

For those files where it cannot determine the original name it will put them in a new lost+found folder it will create.  They will be named after their numerical nodes in the filesystem.  (much like chkdisk used to do on MS-DOS)

 

Joe L.

ok cool thanks.

 

but i just tried to run that command and got the following:

 

Usage: reiserfsck [mode] [options]  device

 

Modes:

  --check                      consistency checking (default)

  --fix-fixable                fix corruptions which can be fixed without

                                --rebuild-tree

  --rebuild-sb                  super block checking and rebuilding if needed

                                (may require --rebuild-tree afterwards)

  --rebuild-tree                force fsck to rebuild filesystem from scratch

                                (takes a long time)

  --clean-attributes            clean garbage in reserved fields in StatDatas

Options:

  -j | --journal device        specify journal if relocated

  -B | --badblocks file        file with list of all bad blocks on the fs

  -l | --logfile file          make fsck to complain to specifed file

  -n | --nolog                  make fsck to not complain

  -z | --adjust-size            fix file sizes to real size

  -q | --quiet                  no speed info

  -y | --yes                    no confirmations

  -V                            prints version and exits

  -a and -p                    some light-weight auto checks for bootup

  -f and -r                    ignored

Expert options:

  --no-journal-available        do not open nor replay journal

  -S | --scan-whole-partition  build tree of all blocks of the device

ok cool thanks.

 

but i just tried to run that command and got the following:

 

Usage: reiserfsck [mode] [options]  device

 

Modes:

  --check                       consistency checking (default)

  --fix-fixable                 fix corruptions which can be fixed without

                                --rebuild-tree

  --rebuild-sb                  super block checking and rebuilding if needed

                                (may require --rebuild-tree afterwards)

  --rebuild-tree                force fsck to rebuild filesystem from scratch

                                (takes a long time)

  --clean-attributes            clean garbage in reserved fields in StatDatas

Options:

  -j | --journal device         specify journal if relocated

  -B | --badblocks file         file with list of all bad blocks on the fs

  -l | --logfile file           make fsck to complain to specifed file

  -n | --nolog                  make fsck to not complain

  -z | --adjust-size            fix file sizes to real size

  -q | --quiet                  no speed info

  -y | --yes                    no confirmations

  -V                            prints version and exits

  -a and -p                     some light-weight auto checks for bootup

  -f and -r                     ignored

Expert options:

  --no-journal-available        do not open nor replay journal

  -S | --scan-whole-partition   build tree of all blocks of the device

You probably mis-typed something.  There are two dashes before the "rebuild" and "scan"

 

reiserfsck --scan-whole-partition --rebuild-tree /dev/md9

 

ok that seemed to do the trick - after it completed, i stopped and started the array and now disk 9 show up correctly.  there are 11 files in the lost+found folder, and i am just wondering how i am supposed to figure out what those files are.  since there is no extension i cant just double click them - any idea how to determine what those files are?

 

ok that seemed to do the trick - after it completed, i stopped and started the array and now disk 9 show up correctly.  there are 11 files in the lost+found folder, and i am just wondering how i am supposed to figure out what those files are.  since there is no extension i cant just double click them - any idea how to determine what those files are?

 

I doubt you can double-click them... but their size would be one clue...  Odds are they were once in your top level folder on disk9, since it would never be able to recover the names of those files, but usually does recover names with them in sub-directories.

 

You can try adding different extensions in turn on those 11 files and then try to open them.   Hey... it's better than not having them at all.

 

Did you also recover other files on the disk?  Ones where it was able to recover the proper names?

 

Joe L.

ok i kinda figured that was the case but though i should ask on the outside chance that you had some kind of trick for this.

 

there are several files which are still intact on that drive so i think i'm in good shape.

 

 

thanks for all your help

 

Sometimes, if the files contain readable text, you can look at the contents and determine what they were.

 

Type

cat filename | strings -10 | head -50

 

and it will print out the first 50 string of 10 characters that are ascii text.  It might not be actual text, but it might help.

 

or

cat filename | strings > strings.txt

and it will put all the readable strings in the file strings.txt for you to look at in an editor.

actually i just got them all back - my first guess of file extension was correct on all of them (.dvr-ms).  they were all old recorded tv shows from my media center.

 

thanks again for all your help!!

actually i just got them all back - my first guess of file extension was correct on all of them (.dvr-ms).  they were all old recorded tv shows from my media center.

 

thanks again for all your help!!

That is great news...

Now, just to be safe... do a full parity check.  Odds are it will find nothing..

IN this situation, where after the original problem there *seemed* to be no missing data (presumably because parity was covering it) is it also an option to just remove the disk from the array and re add it and have it rebuilt from parity?

IN this situation, where after the original problem there *seemed* to be no missing data (presumably because parity was covering it) is it also an option to just remove the disk from the array and re add it and have it rebuilt from parity?

In the past, it has not worked as an option.

 

In all other cases I've helped on, the parity disk has had exactly the same contents as the physical disk, a corrupted superblock.  Therefore, a disk that is "rebuilt" will also have a damaged superblock, and will be un-mountable, and be reported as "un-formatted."

 

It is easy enough to test though, and that is to unplug the failed disk.  unRAID would then be forced to use the emulated contents based on parity and the other disks.  If it (the emulated disk) is able to be mounted, and you can see your missing files, then you can just rebuild onto a new disk.

 

Otherwise, we need to go through the process of rebuilding the superblock, rebuilding the directory tree, etc.

 

I'm pretty sure in one case in the past, a new physical disk was installed, the corrupted contents rebuilt onto it, and then its corrupted superblock repaired to where the disk could again be mounted.

 

Joe L.