Hi everyone,

 

I've been running UnRAID pro 4.7 for a couple of years without any issues, I don't find everything easily intuitive but fingers crossed for version 5.

 

Anyway, my issues started a couple of weeks ago, I received an email informing me of a disk (disk 5) either disabled or invalid.

 

From the web interface Disk 5 had a red ball next to it. (Not all disks were new when I build this server array so I presumed it to be dead and as I had a spare 2TB I thought that the safest thing would be to replace it then test the replaced disk another time.)

 

With disk 5 mapped to my Windows server I saw that all my data was still present, the parity drive doing it's job.

 

I shutdown the array cleanly, replaced disk 5 and restarted the server.

The parity resync took over 10 hours but completed ok.

 

Here's my mistake, I replaced what I thought to be Disk 5 but I "think" that I replaced disk 9 by mistake and only noticed a few days later as everything was green on the disk status page.

 

So as the initial error was for disk 5 I thought I'd check the disk I removed using this tool

http://yareg.akucom.de/

 

I saw that the data was there and intact so I shutdown the array and put the disk back in.

 

My problem is that now Disk 9 is empty and Disk 5 has data but shows File System Type as "unknown".

 

Any ideas what I can do? Any advice is appreciated.

Thanks

I've attached the latest syslog and SMART checks on disks 5 and 9.

 

Syslog here http://pastebin.com/Qid245mK

smart-disk5.txt

smart-disk9.txt

Ok, as I've no advise so far can someone tell me the best thing to do with Disk 5?

As you can see the file system is unknown.

 

Ok, as I've no advise so far can someone tell me the best thing to do with Disk 5?

As you can see the file system is unknown.

 

unknown simply indicates the disk is unable to be mounted.

 

Step 1.  double check the partition points correctly.    (This is for disks <= 2.2 TB with a MBR partition..)

type:

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

 

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 the file-system actually starts on sector 64 you would see:

0098352 002  \0 002  \0  R  e  I  s  E  r  2  F  s  \0  \0  \0

Note, the starting address is different.

 

Next, look at the actual

partition with

fdisk -lu /dev/sdX

 

If no reiserfs found (you did not see a "R  e  I  s  E  r  2  F    s" string at all) , sorry.    You can attempt to rebuild the superblock, but it might not have a file-system regardless.  Note that you  must answer the prompts in that command and they responses are NOT the defaults.  Seek advice in the wiki for how to respond.

 

Seek additional advice with the output of the "dd" command as well if no"reiserfs" string is found.

 

If the fdisk command shows a DIFFERENT partition start than where the "R  e  I  s  E  r  2  F  s" is found, you can use the unraid_partitioin_disk.sh program to fix the partition information in the MBR.  (It is a script I wrote to help another unRAID user)  Seek help before using it to make sure you are using it correctly.

 

If both the partition location start in the MBR and the  "R  e  I  s  E  r  2  F  s" match, but the file-system does not mount, it probably needs repair.

 

Type

reiserfsck --check /dev/mdX

to check it.

 

If it is OK, but the file-system still does not mount, type:

reiserfsck --rebuild-tree /dev/mdX

 

then try once more.

 

Joe L.

Hi Joe,

 

Thanks a lot for your answer, I'll do what you suggest but before then I'd like to know what you think as the disk is mounted and in use.

 

 

It's also a mapped drive avaiable from my Windows machine.

Then don't do anything.

 

If the disk is in use, there is nothing wrong, as it is already mounted. 

(and I'm apparently wasting my time attempting to help you get it mounted)

 

Joe L.

I appreciate any advise and don't think you're wasting your time helping me out.

 

Yes Disk 5 is mounted but I wondered why UnRAID was reporting as it having an unknown file system (even after a clean shutdown and restart). The fact that the original problem also started with a red ball next to disk 5 indicated that there was indeed something wrong.

 

I mention in my first post that I mistakenly replaced Disk 9 with a new disk then checked the removed disk9 outside of the array and then re-added back to the array (in it's original position)

 

As Disk 5 seems to be ok, I wonder if there's anything I can do to see the data again on disk 9? The screenshot in my last post shows 20,350 errors on disk 9.

I don't knw the best way to proceed so, that's why I came for advise here.

 

Disk9 is failing... Replace it, RMA it.

 

It has nearly 400 sectors pending re-allocation.

197 Current_Pending_Sector  0x0032  199  198  000    Old_age  Always      -      399

 

Post the output of

fdisk -lu /dev/sdX

for the disk not indicating a file-system type.  It might provide a clue.

(I have absolutely no idea what unRAID uses to determine FS type, but if it is mounting, it is not an immediate issue)

I will replace Disk 9 as you suggest.

Do you think it's possible that UnRAID mistakenly reported a problem with Disk 5 instead of Disk 9?

 

Here's the output you asked for.

 

 

Disk /dev/sdl: 2000.3 GB, 2000398934016 bytes

1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0xcf32c2b7

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sdl1              63  3907029167  1953514552+  83  Linux

Partition 1 does not end on cylinder boundary.

 

I will replace Disk 9 as you suggest.

Do you think it's possible that UnRAID mistakenly reported a problem with Disk 5 instead of Disk 9?

No, disk5 was disabled becausea "write" to it failed.    It could be anything, including a loose connection you subsequently corrected by moving disks around.

Here's the output you asked for.

 

 

Disk /dev/sdl: 2000.3 GB, 2000398934016 bytes

1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0xcf32c2b7

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sdl1              63  3907029167  1953514552+  83  Linux

Partition 1 does not end on cylinder boundary.

Looks normal.  I was looking for the "83 Linux" and it is there.

 

unRAID must track the file-system type elsewhere..

(and it does not matter what shows on that link, as unRAID only uses reiserfs, and it is reiserfs, and it mounting)

 

Basically, ignore the "unknown" type, as unRAID is not concerned.

 

Joe L.

Thank you Joe for all your help.

 

If I manage to get another disk today I'll replace Disk 9 tonight.

 

Do you think it's safe to trust parity to correct any issues it may find?

 

Also, if parity does it's job, shouldn't I then see the data that was previously on Disk 9?

 

Thank you Joe for all your help.

 

If I manage to get another disk today I'll replace Disk 9 tonight.

 

Do you think it's safe to trust parity to correct any issues it may find?

You have no choice otherwise. It is why you must always have trust in ALL your drives, as they ALL are involved when re-constructing a failed drive.

 

Also, if parity does it's job, shouldn't I then see the data that was previously on Disk 9?

No, you'll see exactly what is on there now.  Nothing more.

 

You can stop the array, un-assign disk 9, and then start the array with it un-assigned.  What you then see on disk 9 in simulated mode is exactly what it will re-construct.

 

When you install the new disk9, just press "Start" to have it reconstruct onto the replacement.  (You may have to check the 'I'm sure" box to enable "Start")

 

DO NOT set a new disk configuration, or you'll invalidate parity and forfeit any chance of reconstruction onto the new disk9.

Ok, great. I'll try that tonight and let you know any progress.

 

Thanks again Joe.

I didn't have time to get another disk today but tonight I was trying to find exactly what data is missing which is extremely difficult as "root" folders on disks overflow to other disks.

Anyway, I rescanned my TV library and I noticed that the folder keeps getting created on my cache drive. I moved the folder to another drive with some free space but it keeps getting recreated on the cache drive, it seems that UnRAID has lost which disk is which, is there a way to "reset" to how things were before?

From your first post. The first part of the failure when you think you accidentally replaced and rebuilt disk9 when disk5 was red-balled can't have happened. It's not possible. unRAID would force you to first fix disk5, and the only way to fix a red-balled drive is to rebuild it. So, your explanation of what happened doesn't make any sense. Tell exactly what steps did you take to get the "parity resync" started.

 

The next part where you saw the data and then just put the disk back into the server can't happen either. How did you manage that? Tell the exact steps and commands used to do this too.

 

Personally, in the first step, I'm thinking you replaced disk9, did an "initconfig" and then formatted disk9 and built the parity, losing all the data you had on disk9. I have no idea what you did to put that disk back.

 

For your later posts. If disk9 is empty then you can try to rebuild from parity but you don't need to rebuilt from parity since there is no data to recover.

 

From your last post. You have to tell us what this re-scanning means. We have no idea what you are doing there. Any new files will go to the cache if this rescanning creates new files in the user share and the user share is set to use the cache.