Hello,

I need some help... understanding how to handle the following situation

- my parity drive is a SATA drive connected to the M/B

- I had 3 PATA disks connected to a Promise TX2 ATA controller.

- one of the PATA disks disappeared from bios report and UnRaid - probably the add-on controller went bad

- I've just moved all the PATA drives to the PATA connectors on the M/B, and reassigned the drives in unraid devices menu

- now all hard drives show up in BIOS without any error

- they now also show up in the main unraid status screen

- however the drive which went off-line (completely missing from bios) is now shown with a blue dot beside

- the array is stopped - the message says "disabled disk replaced". Start will bring the array on-line, will start data rebuild and then expand the file system (if possible).

- the drive does not have any problem, I don't know how to add it back to unraid w/o rebuilding it; I'd just run a file system check to make sure everything is intact (as it probably is)

 

Your advice is very much appreciated.

 

Thank you,

hg

 

PS: a couple of upgrades to the message above...

- I should have posted the message in 4.2 section of the forum, since I'm using 4.2.1 unraid/ Tom, will you be able to move it, shall I just repost?

- I just finished a reiserfsck on the respective drive, and here is the output, showing no major issues:

*************************************************************

 

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

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 Tue Jan 15 15:22:05 2008

###########

Replaying journal..

Trans replayed: mountid 44, transid 29593, desc 4849, len 1, commit 4851, next trans offset 4834

Trans replayed: mountid 44, transid 29594, desc 4852, len 1, commit 4854, next trans offset 4837

Reiserfs journal '/dev/hdd1' in blocks [18..8211]: 2 transactions replayed

Checking internal tree..finished

Comparing bitmaps..finished

Checking Semantic tree: finished

No corruptions found

There are on the filesystem:

        Leaves 57290

        Internal nodes 355

        Directories 1215

        Other files 27819

        Data block pointers 55305686 (0 of them are zero)

        Safe links 0

###########

reiserfsck finished at Tue Jan 15 15:24:27 2008

###########

root@Tower:~#

root@Tower:~#

A drive only gets 'disabled' when a write to it fails.  But, if you are confident the drive and all it's data is ok, then you do a 'Restore' operation which will make all the drives look 'new'.  Then a subsequent Start will rebuild parity.  Otherwise clicking 'Start' now will start a reconstruct of your drive.  If you know parity was good before the controller died, then I would just start the array and rebuild the data drive.

Well, thanks very much for the quick response.

 

Is the fsck attached earlier of any indication that the disk is actually OK?

 

I'm not sure anymore which reference I should trust (the parity disk, or the data drive).

 

I had a few issues with the controller, but everything is fairly new, including the parity disk, to the extent that I can't tell if one is better than the other.

 

A different issue which showed up earlier (before the hardware failure), I found in the syslog:

a particular task was complaining that some file links already existed. I don't know if that was a symptom related to the beginning of the controller failure.

 

Thanks again,

Hg

The output of reiserfsck above looks normal.

 

Regarding "file already exists" in the syslog - this probably a case where User shares are enabled and you have the same file on two or more data disks.  I'd have to see the syslog to be sure...

 

As for your array config, here's something you can try.

 

1. The array status, ie, which disks make up the array and which disk, if any, is disabled, etc. is kept in the file 'super.dat' in the config directory of the Flash.  So navigate to the Flash share and drag a copy of this file to your PC desktop.  Now you can make some config changes and still restore the original config if necessary.

 

2. Go to the Devices page and unassign your parity disk.

 

3. Go back to the Main page, click 'Restore' and then 'Start'.  Now all your data disks will come on-line.

 

4. You can now browse your shares and if everything looks ok, Stop the array, go back to the Devices page and re-assign your parity disk. Then Start the array again and it will start parity sync.

 

5. If it looks like there are problems with the previously 'disabled' disk, then you can restore the super.dat file and start a normal reconstruct.

Hello;

 

I'm a bit slow in making some progress and updating you...

 

Thank you for your clarifications.

 

Here are some learnings - perhaps useful to others. My earlier disk problems were due to an unreliable power supply. Despite the fact that it was a 480W PS, when I started adding 2 more hard drives caused the system to behave strange. The Promise ATA controller works just fine, as do the hard drives, after installing a new power supply (550W).

 

After having reinstalled everything back, I have created a new parity disk (the same, but re-sync-ed, as you advised me), keeping the data disks as they were, and counting on the integrity of my stored information.

 

The next item on my list of questions was related to duplicate links. I have just ran a "find" on the the disks (in a terminal window), and indeed the same files show up on both disks. This seems to be limited to only a few, but it is strange, and can't understand what is the reason for that, and how to avoid such unnecessary duplication.

 

Here is the output of that find:

 

root@Tower:~# find / -name 'Micheal Jackson'* -exec ls -l {} \;

lrwxrwxrwx 1 root root 87 Jan 30 23:45 /mnt/tmp/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg -> /mnt/disk1/Video/Music Cli

cheal Jackson Video Concert - Billie Jean.mpg

-rwx------ 1 root root 53577500 Jan 14  2003 /mnt/user/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg

-rwx------ 1 root root 53577500 Jan 14  2003 /mnt/disk2/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg

-rwx------ 1 root root 53577500 Jan 14  2003 /mnt/disk1/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg

root@Tower:~#

Thank you,

 

HG

The files on disk1 and disk2 seem to be identical as they are the same size in bytes.

 

To be sure they are, you can do a md5 checksum on them as follows... if they are identical checksums, then you can remove one of the two and reclaim some space on one of your drives.  If they are different, you will need to play each in turn to determine which to keep.

 

md5sum "/mnt/disk1/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg"

md5sum "/mnt/disk2/Video/Music Clips & Concerts/Micheal Jackson Video Concert - Billie Jean.mpg"

 

Joe L.

Thanks - excellent suggestion!

I'll check them before removing.

 

Any idea why this happened, can I avoid this situation?

 

Thank you,

HG

Thanks - excellent suggestion!

I'll check them before removing.

 

Any idea why this happened, can I avoid this situation?

 

Thank you,

HG

First, only remove one of the two files, and NOT the one on /mnt/usr, since it is the user-share link to the real file.

Second, since we don't know which one it is linked to, after you remove one of the other two the user share link might (50% chance) not point to a file any longer.  Just stop the array and restart it. It will figure things out.

 

Since you are the first and only person to report this, at least so far, is it possible made both copies yourself?

Thank you, Joe.

 

I started removing the duplicate files mindful of the links - and removing only those not linked.

 

As for the possibility that I may have created those myself... Could very well be the case, can't really know, since I transferred files in batches, from different hard drives. On the other hand, there was a remark in one of the answers, regarding the user shares, which may be the source of the confusion.

 

I'll watch the problem and post here if any other findings.

 

Thanks much again,

 

HG