RE: Raid 5 Issue, cannot recognize EXT3 File system.

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

I am also able to see the filesystem of the NAS, however not the data
partition. EX:

I can see the filesystem on:
#ls /media/disk (which is the mount of the filesystem in the NAS) This is
also considered to be my /dev/md0, /dev/md2 is the data partition

-----Original Message-----
From: Sunpyo Hong [mailto:sunpyo.hong@amac.com] 
Sent: Thursday, September 17, 2009 5:47 PM
To: 'Robin Hill'; 'linux-raid@vger.kernel.org'
Subject: RE: Raid 5 Issue, cannot recognize EXT3 File system.

First off, lemme tell you the initial problem. I had a WD ShareSpace that
had one of the disk go bad. They sent a replacement and it was suppose to
rebuild on its own, however after the build, the array went bad and it was
no longer able to see any of the files. 

I downloaded and tested the drives using windows data recovery tools I saw
that the ext3 was Linux FS and that using these tools would not help in the
recovery. However through the tools I was able to see and recover some of
the files, but the files themselves were usable. I confirmed with WD that
ext3 was in fact the FS and took steps to recover the data. These are the
steps I took in order for me to assemble the raid.

Right now I have 3/4 drives with the data. I did #mdadm --assemble --scan,
which let me assemble the raid. However at this point I was not able to see
any of the files or mount the drive to the mount point it was once at. I
have also tried #mdadm --create with the array in the right order /w the
missing disk. 

Initially the --assemble --scan assembled the array /dev/md2 with the disks
in the wrong order. I know because I physically saw where the disks were in
relation to the disk order and wrote down the disk order on every HD.

Here's everything I could find in terms of information that you asked for.
It's a lot.

#dmesg
[  339.440187] raid5: device sdb4 operational as raid disk 1
[  339.440189] raid5: device sdd4 operational as raid disk 3
[  339.440192] raid5: device sdc4 operational as raid disk 2
[  339.440610] raid5: allocated 4219kB for md2
[  339.440612] raid5: raid level 5 set md2 active with 3 out of 4 devices,
algorithm 2
[  339.440615] RAID5 conf printout:
[  339.440617]  --- rd:4 wd:3
[  339.440619]  disk 1, o:1, dev:sdb4
[  339.440620]  disk 2, o:1, dev:sdc4
[  339.440622]  disk 3, o:1, dev:sdd4
[  339.440817]  md2: unknown partition table
[  538.840033] kjournald starting.  Commit interval 5 seconds
[  538.891844] EXT3 FS on md0, internal journal
[  538.891849] EXT3-fs: mounted filesystem with ordered data mode.
[  581.585031] VFS: Can't find ext4 filesystem on dev md2.
[  587.056825] VFS: Can't find ext3 filesystem on dev md2.


#fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      243202  1953514583+  ee  GPT

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e3

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdb2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdb3             157         182      208845   fd  Linux raid
autodetect
/dev/sdb4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdc2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdc3             157         182      208845   fd  Linux raid
autodetect
/dev/sdc4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e2

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdd2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdd3             157         182      208845   fd  Linux raid
autodetect
/dev/sdd4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/md0: 213 MB, 213778432 bytes
2 heads, 4 sectors/track, 52192 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md2: 5996.6 GB, 5996697747456 bytes
2 heads, 4 sectors/track, 1464037536 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md2 doesn't contain a valid partition table


#cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      
md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
      208768 blocks [4/3] [UUU_]
      

#cat /etc/fstab
aufs / aufs rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0
/dev/sda2 swap swap defaults 0 0
/dev/sdb2 swap swap defaults 0 0
/dev/sdc2 swap swap defaults 0 0
/dev/sdd2 swap swap defaults 0 0


#mount -t ext3 /dev/md2 /media/disk/shares
mount: wrong fs type, bad option, bad superblock on /dev/md2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

#mdadm -Ds -v
ARRAY /dev/md0 level=raid1 num-devices=4 metadata=00.90
UUID=15e54255:f58be7ca:7f4a592f:038fedf2
   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md2 level=raid5 num-devices=4 metadata=00.90
UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
   devices=/dev/sdb4,/dev/sdc4,/dev/sdd4

#mdadm -Es -v
ARRAY /dev/md0 level=raid1 num-devices=4
UUID=15e54255:f58be7ca:7f4a592f:038fedf2
   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md1 level=raid1 num-devices=4
UUID=57cd5e76:0d56f114:50bd5336:4477d020
   devices=/dev/sdd2,/dev/sdc2,/dev/sdb2
ARRAY /dev/md2 level=raid5 num-devices=4
UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
   devices=/dev/sdd4,/dev/sdc4,/dev/sdb4

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
Sent: Thursday, September 17, 2009 5:02 PM
To: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:

> I've contacted just about everyone that knows a thing about RAID5, but no
> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays
and
> how to properly assemble them. However I've run into a problem with a NAS
> system from WD that I just can't seem to figure out.
> 
> I have a ¾ disks in the array, 1 went down and is out of commission.  I've
> been able to assemble my array through mdadm using --assemble --scan.
However
> I cannot access the array due to the fact that the array cannot read a
> filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I
> know that the FS is an ext3 FS. However I cannot seem to get this
> thing going. I was wondering if anyone could point me in the right
> direction with this. I can't seem to find anyone that is capable of
> solving this. I would appreciate any help. Thanks!
> 
What's the output of 'cat /proc/mdstat' after you assemble the array?
And what exact error (and dmesg output) do you get when trying to mount
it as ext3?

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Majed B.]

Can you show the output of dmesg after you try to mount (and fail), to
see more details on what's going wrong with the filesystem?

On Fri, Sep 18, 2009 at 12:54 AM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
> I am also able to see the filesystem of the NAS, however not the data
> partition. EX:
>
> I can see the filesystem on:
> #ls /media/disk (which is the mount of the filesystem in the NAS) This is
> also considered to be my /dev/md0, /dev/md2 is the data partition
>
> -----Original Message-----
> From: Sunpyo Hong [mailto:sunpyo.hong@amac.com]
> Sent: Thursday, September 17, 2009 5:47 PM
> To: 'Robin Hill'; 'linux-raid@vger.kernel.org'
> Subject: RE: Raid 5 Issue, cannot recognize EXT3 File system.
>
> First off, lemme tell you the initial problem. I had a WD ShareSpace that
> had one of the disk go bad. They sent a replacement and it was suppose to
> rebuild on its own, however after the build, the array went bad and it was
> no longer able to see any of the files.
>
> I downloaded and tested the drives using windows data recovery tools I saw
> that the ext3 was Linux FS and that using these tools would not help in the
> recovery. However through the tools I was able to see and recover some of
> the files, but the files themselves were usable. I confirmed with WD that
> ext3 was in fact the FS and took steps to recover the data. These are the
> steps I took in order for me to assemble the raid.
>
> Right now I have 3/4 drives with the data. I did #mdadm --assemble --scan,
> which let me assemble the raid. However at this point I was not able to see
> any of the files or mount the drive to the mount point it was once at. I
> have also tried #mdadm --create with the array in the right order /w the
> missing disk.
>
> Initially the --assemble --scan assembled the array /dev/md2 with the disks
> in the wrong order. I know because I physically saw where the disks were in
> relation to the disk order and wrote down the disk order on every HD.
>
> Here's everything I could find in terms of information that you asked for.
> It's a lot.
>
> #dmesg
> [  339.440187] raid5: device sdb4 operational as raid disk 1
> [  339.440189] raid5: device sdd4 operational as raid disk 3
> [  339.440192] raid5: device sdc4 operational as raid disk 2
> [  339.440610] raid5: allocated 4219kB for md2
> [  339.440612] raid5: raid level 5 set md2 active with 3 out of 4 devices,
> algorithm 2
> [  339.440615] RAID5 conf printout:
> [  339.440617]  --- rd:4 wd:3
> [  339.440619]  disk 1, o:1, dev:sdb4
> [  339.440620]  disk 2, o:1, dev:sdc4
> [  339.440622]  disk 3, o:1, dev:sdd4
> [  339.440817]  md2: unknown partition table
> [  538.840033] kjournald starting.  Commit interval 5 seconds
> [  538.891844] EXT3 FS on md0, internal journal
> [  538.891849] EXT3-fs: mounted filesystem with ordered data mode.
> [  581.585031] VFS: Can't find ext4 filesystem on dev md2.
> [  587.056825] VFS: Can't find ext3 filesystem on dev md2.
>
>
> #fdisk -l
> WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
> doesn't support GPT. Use GNU Parted.
>
>
> Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0x00000000
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1      243202  1953514583+  ee  GPT
>
> Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e3
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdb2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdb3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdb4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e4
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdc1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdc2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdc3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdc4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e2
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdd1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdd2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdd3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdd4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/md0: 213 MB, 213778432 bytes
> 2 heads, 4 sectors/track, 52192 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md0 doesn't contain a valid partition table
>
> Disk /dev/md2: 5996.6 GB, 5996697747456 bytes
> 2 heads, 4 sectors/track, 1464037536 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md2 doesn't contain a valid partition table
>
>
> #cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4]
> md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
>      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
>
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>      208768 blocks [4/3] [UUU_]
>
>
> #cat /etc/fstab
> aufs / aufs rw 0 0
> tmpfs /tmp tmpfs nosuid,nodev 0 0
> /dev/sda2 swap swap defaults 0 0
> /dev/sdb2 swap swap defaults 0 0
> /dev/sdc2 swap swap defaults 0 0
> /dev/sdd2 swap swap defaults 0 0
>
>
> #mount -t ext3 /dev/md2 /media/disk/shares
> mount: wrong fs type, bad option, bad superblock on /dev/md2,
>       missing codepage or helper program, or other error
>       In some cases useful info is found in syslog - try
>       dmesg | tail  or so
>
> #mdadm -Ds -v
> ARRAY /dev/md0 level=raid1 num-devices=4 metadata=00.90
> UUID=15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md2 level=raid5 num-devices=4 metadata=00.90
> UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=/dev/sdb4,/dev/sdc4,/dev/sdd4
>
> #mdadm -Es -v
> ARRAY /dev/md0 level=raid1 num-devices=4
> UUID=15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md1 level=raid1 num-devices=4
> UUID=57cd5e76:0d56f114:50bd5336:4477d020
>   devices=/dev/sdd2,/dev/sdc2,/dev/sdb2
> ARRAY /dev/md2 level=raid5 num-devices=4
> UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=/dev/sdd4,/dev/sdc4,/dev/sdb4
>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
> Sent: Thursday, September 17, 2009 5:02 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
>
> On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:
>
>> I've contacted just about everyone that knows a thing about RAID5, but no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays
> and
>> how to properly assemble them. However I've run into a problem with a NAS
>> system from WD that I just can't seem to figure out.
>>
>> I have a ľ disks in the array, 1 went down and is out of commission.  I've
>> been able to assemble my array through mdadm using --assemble --scan.
> However
>> I cannot access the array due to the fact that the array cannot read a
>> filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I
>> know that the FS is an ext3 FS. However I cannot seem to get this
>> thing going. I was wondering if anyone could point me in the right
>> direction with this. I can't seem to find anyone that is capable of
>> solving this. I would appreciate any help. Thanks!
>>
> What's the output of 'cat /proc/mdstat' after you assemble the array?
> And what exact error (and dmesg output) do you get when trying to mount
> it as ext3?
>
> Cheers,
>    Robin
> --
>     ___
>    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
>   / / )      | Little Jim says ....                            |
>  // !!       |      "He fallen in de water !!"                 |
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

Here's some more info:

Before
root@ubuntu:/home/ubuntu# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb4[2] sdc4[1] sdd4[0]
      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      
md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
      208768 blocks [4/3] [UUU_]

Now.
root@ubuntu:/home/ubuntu# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdd4[2] sdb4[1] sdc4[0]
      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      
md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
      208768 blocks [4/3] [UUU_]

[58638.991719] RAID5 conf printout:
[58638.991720]  --- rd:4 wd:3
[58638.991722]  disk 0, o:1, dev:sdc4
[58638.991724]  disk 1, o:1, dev:sdb4
[58638.991726]  disk 2, o:1, dev:sdd4
[58638.993434]  md2: unknown partition table
[58672.600433] VFS: Can't find ext3 filesystem on dev md2.
[59137.799835] md: md2 stopped.
[59137.799848] md: unbind<sdd4>
[59137.800920] md: export_rdev(sdd4)
[59137.800961] md: unbind<sdb4>
[59137.804771] md: export_rdev(sdb4)
[59137.804778] md: unbind<sdc4>
[59137.804808] md: export_rdev(sdc4)
[59166.007689] md: bind<sdd4>
[59166.012173] md: bind<sdc4>
[59166.014076] md: bind<sdb4>
[59166.021627] raid5: device sdb4 operational as raid disk 2
[59166.021630] raid5: device sdc4 operational as raid disk 1
[59166.021633] raid5: device sdd4 operational as raid disk 0
[59166.022090] raid5: allocated 4219kB for md2
[59166.022092] raid5: raid level 5 set md2 active with 3 out of 4 devices,
algorithm 2
[59166.022095] RAID5 conf printout:
[59166.022097]  --- rd:4 wd:3
[59166.022099]  disk 0, o:1, dev:sdd4
[59166.022100]  disk 1, o:1, dev:sdc4
[59166.022102]  disk 2, o:1, dev:sdb4
[59166.023663]  md2: unknown partition table
[59219.038548] VFS: Can't find ext3 filesystem on dev md2.
[59446.152543] kjournald starting.  Commit interval 5 seconds
[59446.153319] EXT3 FS on sda1, internal journal
[59446.153323] EXT3-fs: mounted filesystem with ordered data mode.
[59527.884970] VFS: Can't find ext3 filesystem on dev md2.
[60189.928644] VFS: Can't find ext3 filesystem on dev md2.
[60649.834143] VFS: Can't find ext4 filesystem on dev md2.

-Sunpyo

-----Original Message-----
From: Majed B. [mailto:majedb@gmail.com] 
Sent: Thursday, September 17, 2009 6:09 PM
To: Sunpyo Hong
Cc: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

Can you show the output of dmesg after you try to mount (and fail), to
see more details on what's going wrong with the filesystem?

On Fri, Sep 18, 2009 at 12:54 AM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
> I am also able to see the filesystem of the NAS, however not the data
> partition. EX:
>
> I can see the filesystem on:
> #ls /media/disk (which is the mount of the filesystem in the NAS) This is
> also considered to be my /dev/md0, /dev/md2 is the data partition
>
> -----Original Message-----
> From: Sunpyo Hong [mailto:sunpyo.hong@amac.com]
> Sent: Thursday, September 17, 2009 5:47 PM
> To: 'Robin Hill'; 'linux-raid@vger.kernel.org'
> Subject: RE: Raid 5 Issue, cannot recognize EXT3 File system.
>
> First off, lemme tell you the initial problem. I had a WD ShareSpace that
> had one of the disk go bad. They sent a replacement and it was suppose to
> rebuild on its own, however after the build, the array went bad and it was
> no longer able to see any of the files.
>
> I downloaded and tested the drives using windows data recovery tools I saw
> that the ext3 was Linux FS and that using these tools would not help in
the
> recovery. However through the tools I was able to see and recover some of
> the files, but the files themselves were usable. I confirmed with WD that
> ext3 was in fact the FS and took steps to recover the data. These are the
> steps I took in order for me to assemble the raid.
>
> Right now I have 3/4 drives with the data. I did #mdadm --assemble --scan,
> which let me assemble the raid. However at this point I was not able to
see
> any of the files or mount the drive to the mount point it was once at. I
> have also tried #mdadm --create with the array in the right order /w the
> missing disk.
>
> Initially the --assemble --scan assembled the array /dev/md2 with the
disks
> in the wrong order. I know because I physically saw where the disks were
in
> relation to the disk order and wrote down the disk order on every HD.
>
> Here's everything I could find in terms of information that you asked for.
> It's a lot.
>
> #dmesg
> [  339.440187] raid5: device sdb4 operational as raid disk 1
> [  339.440189] raid5: device sdd4 operational as raid disk 3
> [  339.440192] raid5: device sdc4 operational as raid disk 2
> [  339.440610] raid5: allocated 4219kB for md2
> [  339.440612] raid5: raid level 5 set md2 active with 3 out of 4 devices,
> algorithm 2
> [  339.440615] RAID5 conf printout:
> [  339.440617]  --- rd:4 wd:3
> [  339.440619]  disk 1, o:1, dev:sdb4
> [  339.440620]  disk 2, o:1, dev:sdc4
> [  339.440622]  disk 3, o:1, dev:sdd4
> [  339.440817]  md2: unknown partition table
> [  538.840033] kjournald starting.  Commit interval 5 seconds
> [  538.891844] EXT3 FS on md0, internal journal
> [  538.891849] EXT3-fs: mounted filesystem with ordered data mode.
> [  581.585031] VFS: Can't find ext4 filesystem on dev md2.
> [  587.056825] VFS: Can't find ext3 filesystem on dev md2.
>
>
> #fdisk -l
> WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
> doesn't support GPT. Use GNU Parted.
>
>
> Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0x00000000
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1      243202  1953514583+  ee  GPT
>
> Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e3
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdb2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdb3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdb4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e4
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdc1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdc2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdc3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdc4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xdd07e5e2
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdd1               1          26      208844+  fd  Linux raid
> autodetect
> /dev/sdd2              27         156     1044225   fd  Linux raid
> autodetect
> /dev/sdd3             157         182      208845   fd  Linux raid
> autodetect
> /dev/sdd4             183      243201  1952050117+  fd  Linux raid
> autodetect
>
> Disk /dev/md0: 213 MB, 213778432 bytes
> 2 heads, 4 sectors/track, 52192 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md0 doesn't contain a valid partition table
>
> Disk /dev/md2: 5996.6 GB, 5996697747456 bytes
> 2 heads, 4 sectors/track, 1464037536 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md2 doesn't contain a valid partition table
>
>
> #cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4]
> md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
>      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
>
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>      208768 blocks [4/3] [UUU_]
>
>
> #cat /etc/fstab
> aufs / aufs rw 0 0
> tmpfs /tmp tmpfs nosuid,nodev 0 0
> /dev/sda2 swap swap defaults 0 0
> /dev/sdb2 swap swap defaults 0 0
> /dev/sdc2 swap swap defaults 0 0
> /dev/sdd2 swap swap defaults 0 0
>
>
> #mount -t ext3 /dev/md2 /media/disk/shares
> mount: wrong fs type, bad option, bad superblock on /dev/md2,
>       missing codepage or helper program, or other error
>       In some cases useful info is found in syslog - try
>       dmesg | tail  or so
>
> #mdadm -Ds -v
> ARRAY /dev/md0 level=raid1 num-devices=4 metadata=00.90
> UUID=15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md2 level=raid5 num-devices=4 metadata=00.90
> UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=/dev/sdb4,/dev/sdc4,/dev/sdd4
>
> #mdadm -Es -v
> ARRAY /dev/md0 level=raid1 num-devices=4
> UUID=15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md1 level=raid1 num-devices=4
> UUID=57cd5e76:0d56f114:50bd5336:4477d020
>   devices=/dev/sdd2,/dev/sdc2,/dev/sdb2
> ARRAY /dev/md2 level=raid5 num-devices=4
> UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=/dev/sdd4,/dev/sdc4,/dev/sdb4
>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
> Sent: Thursday, September 17, 2009 5:02 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
>
> On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:
>
>> I've contacted just about everyone that knows a thing about RAID5, but no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays
> and
>> how to properly assemble them. However I've run into a problem with a NAS
>> system from WD that I just can't seem to figure out.
>>
>> I have a ľ disks in the array, 1 went down and is out of commission.
 I've
>> been able to assemble my array through mdadm using --assemble --scan.
> However
>> I cannot access the array due to the fact that the array cannot read a
>> filesystem. Everytime I try to mount I get mount: wrong fs type. etc. I
>> know that the FS is an ext3 FS. However I cannot seem to get this
>> thing going. I was wondering if anyone could point me in the right
>> direction with this. I can't seem to find anyone that is capable of
>> solving this. I would appreciate any help. Thanks!
>>
> What's the output of 'cat /proc/mdstat' after you assemble the array?
> And what exact error (and dmesg output) do you get when trying to mount
> it as ext3?
>
> Cheers,
>    Robin
> --
>     ___
>    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
>   / / )      | Little Jim says ....                            |
>  // !!       |      "He fallen in de water !!"                 |
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

On Mon Sep 21, 2009 at 11:32:17AM -0400, Sunpyo Hong wrote:

> Here's some more info:
> 
> Before
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md2 : active raid5 sdb4[2] sdc4[1] sdd4[0]
>       5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
>       
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>       208768 blocks [4/3] [UUU_]
> 
What exactly is this "before"?  Is this the state of the array when you
first connected (before trying anything else)?  If so, then this should
be the correct device order and chunk size.

Here md2 has the same device order as md0:
    0 => sdd
    1 => sdc
    2 => sdb

> Now.
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md2 : active raid5 sdd4[2] sdb4[1] sdc4[0]
>       5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
>       
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>       208768 blocks [4/3] [UUU_]
> 
And here it has a different order.  If the array mounted fine in the
"Before" state but doesn't now, then I'd say you need to recreate the
array in the correct order.

> [58638.991719] RAID5 conf printout:
> [58638.991720]  --- rd:4 wd:3
> [58638.991722]  disk 0, o:1, dev:sdc4
> [58638.991724]  disk 1, o:1, dev:sdb4
> [58638.991726]  disk 2, o:1, dev:sdd4
> [58638.993434]  md2: unknown partition table
> [58672.600433] VFS: Can't find ext3 filesystem on dev md2.
> [59137.799835] md: md2 stopped.
> [59137.799848] md: unbind<sdd4>
> [59137.800920] md: export_rdev(sdd4)
> [59137.800961] md: unbind<sdb4>
> [59137.804771] md: export_rdev(sdb4)
> [59137.804778] md: unbind<sdc4>
> [59137.804808] md: export_rdev(sdc4)
> [59166.007689] md: bind<sdd4>
> [59166.012173] md: bind<sdc4>
> [59166.014076] md: bind<sdb4>
> [59166.021627] raid5: device sdb4 operational as raid disk 2
> [59166.021630] raid5: device sdc4 operational as raid disk 1
> [59166.021633] raid5: device sdd4 operational as raid disk 0
> [59166.022090] raid5: allocated 4219kB for md2
> [59166.022092] raid5: raid level 5 set md2 active with 3 out of 4 devices,
> algorithm 2
> [59166.022095] RAID5 conf printout:
> [59166.022097]  --- rd:4 wd:3
> [59166.022099]  disk 0, o:1, dev:sdd4
> [59166.022100]  disk 1, o:1, dev:sdc4
> [59166.022102]  disk 2, o:1, dev:sdb4
> [59166.023663]  md2: unknown partition table
> [59219.038548] VFS: Can't find ext3 filesystem on dev md2.
> [59446.152543] kjournald starting.  Commit interval 5 seconds
> [59446.153319] EXT3 FS on sda1, internal journal
> [59446.153323] EXT3-fs: mounted filesystem with ordered data mode.
> [59527.884970] VFS: Can't find ext3 filesystem on dev md2.
> [60189.928644] VFS: Can't find ext3 filesystem on dev md2.
> [60649.834143] VFS: Can't find ext4 filesystem on dev md2.
> 
And this output appears to show it assembling the array in two different
orders (both the "before" and "now" order), and failing to mount it in
either.  Is this from a single boot or is this as you're stopping &
recreating the array?

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

I am stopping and starting the array. I couldn't mount in both instances.
The before is the initial assembly array that I force assembled through
mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.

The after is when I recreated the array. Again I still could not mount.
Again I stopped and started the array.

Sunpyo Hong

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
Sent: Monday, September 21, 2009 11:56 AM
To: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

On Mon Sep 21, 2009 at 11:32:17AM -0400, Sunpyo Hong wrote:

> Here's some more info:
> 
> Before
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md2 : active raid5 sdb4[2] sdc4[1] sdd4[0]
>       5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
>       
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>       208768 blocks [4/3] [UUU_]
> 
What exactly is this "before"?  Is this the state of the array when you
first connected (before trying anything else)?  If so, then this should
be the correct device order and chunk size.

Here md2 has the same device order as md0:
    0 => sdd
    1 => sdc
    2 => sdb

> Now.
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md2 : active raid5 sdd4[2] sdb4[1] sdc4[0]
>       5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
>       
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>       208768 blocks [4/3] [UUU_]
> 
And here it has a different order.  If the array mounted fine in the
"Before" state but doesn't now, then I'd say you need to recreate the
array in the correct order.

> [58638.991719] RAID5 conf printout:
> [58638.991720]  --- rd:4 wd:3
> [58638.991722]  disk 0, o:1, dev:sdc4
> [58638.991724]  disk 1, o:1, dev:sdb4
> [58638.991726]  disk 2, o:1, dev:sdd4
> [58638.993434]  md2: unknown partition table
> [58672.600433] VFS: Can't find ext3 filesystem on dev md2.
> [59137.799835] md: md2 stopped.
> [59137.799848] md: unbind<sdd4>
> [59137.800920] md: export_rdev(sdd4)
> [59137.800961] md: unbind<sdb4>
> [59137.804771] md: export_rdev(sdb4)
> [59137.804778] md: unbind<sdc4>
> [59137.804808] md: export_rdev(sdc4)
> [59166.007689] md: bind<sdd4>
> [59166.012173] md: bind<sdc4>
> [59166.014076] md: bind<sdb4>
> [59166.021627] raid5: device sdb4 operational as raid disk 2
> [59166.021630] raid5: device sdc4 operational as raid disk 1
> [59166.021633] raid5: device sdd4 operational as raid disk 0
> [59166.022090] raid5: allocated 4219kB for md2
> [59166.022092] raid5: raid level 5 set md2 active with 3 out of 4 devices,
> algorithm 2
> [59166.022095] RAID5 conf printout:
> [59166.022097]  --- rd:4 wd:3
> [59166.022099]  disk 0, o:1, dev:sdd4
> [59166.022100]  disk 1, o:1, dev:sdc4
> [59166.022102]  disk 2, o:1, dev:sdb4
> [59166.023663]  md2: unknown partition table
> [59219.038548] VFS: Can't find ext3 filesystem on dev md2.
> [59446.152543] kjournald starting.  Commit interval 5 seconds
> [59446.153319] EXT3 FS on sda1, internal journal
> [59446.153323] EXT3-fs: mounted filesystem with ordered data mode.
> [59527.884970] VFS: Can't find ext3 filesystem on dev md2.
> [60189.928644] VFS: Can't find ext3 filesystem on dev md2.
> [60649.834143] VFS: Can't find ext4 filesystem on dev md2.
> 
And this output appears to show it assembling the array in two different
orders (both the "before" and "now" order), and failing to mount it in
either.  Is this from a single boot or is this as you're stopping &
recreating the array?

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[NeilBrown]

On Tue, September 22, 2009 2:14 am, Sunpyo Hong wrote:
> I am stopping and starting the array. I couldn't mount in both instances.
> The before is the initial assembly array that I force assembled through
> mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.

I haven't followed all of this thread, so maybe I missed something,
but have you considered the possibility that there is an LVM config
on the md array, and that the ext3 filesystem is inside a logical
volume?

NeilBrown

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

> I am stopping and starting the array. I couldn't mount in both instances.
> The before is the initial assembly array that I force assembled through
> mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.

>I haven't followed all of this thread, so maybe I missed something,
>but have you considered the possibility that there is an LVM config
>on the md array, and that the ext3 filesystem is inside a logical
>volume?

>NeilBrown

Hi Neil, I already checked with western digital and its support team. What
they've told me is that the Raid is an EXT3 and is not LVM config on the HD,
however knowing WD they might just say that so I'd fork over the cash to get
my HD recovered for thousands of dollars from them. Is there a way I can
check if it's LVM config-ed? Thanks!

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Majed B.]

When the array is properly assembled, "sudo lvscan" should show any
logical volumes. Maybe even without the array assembled.

If nothing shows up, then you don't have an LV configured.

On Tue, Sep 22, 2009 at 6:15 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
>> I am stopping and starting the array. I couldn't mount in both instances.
>> The before is the initial assembly array that I force assembled through
>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.
>
>>I haven't followed all of this thread, so maybe I missed something,
>>but have you considered the possibility that there is an LVM config
>>on the md array, and that the ext3 filesystem is inside a logical
>>volume?
>
>>NeilBrown
>
> Hi Neil, I already checked with western digital and its support team. What
> they've told me is that the Raid is an EXT3 and is not LVM config on the HD,
> however knowing WD they might just say that so I'd fork over the cash to get
> my HD recovered for thousands of dollars from them. Is there a way I can
> check if it's LVM config-ed? Thanks!
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

Nothing showed up when I did  "sudo lvscan". I'm pretty much stumped.

-----Original Message-----
From: Majed B. [mailto:majedb@gmail.com] 
Sent: Tuesday, September 22, 2009 11:24 AM
To: Sunpyo Hong
Cc: Robin Hill; linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

When the array is properly assembled, "sudo lvscan" should show any
logical volumes. Maybe even without the array assembled.

If nothing shows up, then you don't have an LV configured.

On Tue, Sep 22, 2009 at 6:15 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
>> I am stopping and starting the array. I couldn't mount in both instances.
>> The before is the initial assembly array that I force assembled through
>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.
>
>>I haven't followed all of this thread, so maybe I missed something,
>>but have you considered the possibility that there is an LVM config
>>on the md array, and that the ext3 filesystem is inside a logical
>>volume?
>
>>NeilBrown
>
> Hi Neil, I already checked with western digital and its support team. What
> they've told me is that the Raid is an EXT3 and is not LVM config on the
HD,
> however knowing WD they might just say that so I'd fork over the cash to
get
> my HD recovered for thousands of dollars from them. Is there a way I can
> check if it's LVM config-ed? Thanks!
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Majed B.]

If you are sure that you have created the array with the proper order
of disks (They MUST be in the correct order! Your disks may have
changed their names for some reason -- verify that they are in
order!!) and that you have assembled them properly, I would suggest
you run a tool called "testdisk"

You may have a corrupt filesystem, and testdisk would try to fix it.
Also, to make sure that you have assembled the array in the correct
order, and if the filesystem can't be fixed if it's corrupt, use a
file-recovery tool like foremost or magicrescue and see if they
recover your data.

On Tue, Sep 22, 2009 at 9:42 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
> Nothing showed up when I did  "sudo lvscan". I'm pretty much stumped.
>
> -----Original Message-----
> From: Majed B. [mailto:majedb@gmail.com]
> Sent: Tuesday, September 22, 2009 11:24 AM
> To: Sunpyo Hong
> Cc: Robin Hill; linux-raid@vger.kernel.org
> Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
>
> When the array is properly assembled, "sudo lvscan" should show any
> logical volumes. Maybe even without the array assembled.
>
> If nothing shows up, then you don't have an LV configured.
>
> On Tue, Sep 22, 2009 at 6:15 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
>>> I am stopping and starting the array. I couldn't mount in both instances.
>>> The before is the initial assembly array that I force assembled through
>>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file system.
>>
>>>I haven't followed all of this thread, so maybe I missed something,
>>>but have you considered the possibility that there is an LVM config
>>>on the md array, and that the ext3 filesystem is inside a logical
>>>volume?
>>
>>>NeilBrown
>>
>> Hi Neil, I already checked with western digital and its support team. What
>> they've told me is that the Raid is an EXT3 and is not LVM config on the
> HD,
>> however knowing WD they might just say that so I'd fork over the cash to
> get
>> my HD recovered for thousands of dollars from them. Is there a way I can
>> check if it's LVM config-ed? Thanks!
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
>       Majed B.
>
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Guy Watkins]

I have not paid attention to this thread.  So, might be asking a stupid
question...

Are the disks from a system of the same platform?  If not, maybe the byte
ordering is different?  I think I recall this as an issue with the 0.9
superblock, but I think it was not an issue with a newer superblock.  Maybe
it was just a feature request.  Not sure.

Anyway, mdadm supports "byteorder".  man mdadm for more info.  I have never
used it.

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Majed B.
} Sent: Tuesday, September 22, 2009 8:14 PM
} To: Sunpyo Hong
} Cc: Robin Hill; linux-raid@vger.kernel.org
} Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
} 
} If you are sure that you have created the array with the proper order
} of disks (They MUST be in the correct order! Your disks may have
} changed their names for some reason -- verify that they are in
} order!!) and that you have assembled them properly, I would suggest
} you run a tool called "testdisk"
} 
} You may have a corrupt filesystem, and testdisk would try to fix it.
} Also, to make sure that you have assembled the array in the correct
} order, and if the filesystem can't be fixed if it's corrupt, use a
} file-recovery tool like foremost or magicrescue and see if they
} recover your data.
} 
} On Tue, Sep 22, 2009 at 9:42 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
} > Nothing showed up when I did  "sudo lvscan". I'm pretty much stumped.
} >
} > -----Original Message-----
} > From: Majed B. [mailto:majedb@gmail.com]
} > Sent: Tuesday, September 22, 2009 11:24 AM
} > To: Sunpyo Hong
} > Cc: Robin Hill; linux-raid@vger.kernel.org
} > Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
} >
} > When the array is properly assembled, "sudo lvscan" should show any
} > logical volumes. Maybe even without the array assembled.
} >
} > If nothing shows up, then you don't have an LV configured.
} >
} > On Tue, Sep 22, 2009 at 6:15 PM, Sunpyo Hong <sunpyo.hong@amac.com>
} wrote:
} >>> I am stopping and starting the array. I couldn't mount in both
} instances.
} >>> The before is the initial assembly array that I force assembled
} through
} >>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file
} system.
} >>
} >>>I haven't followed all of this thread, so maybe I missed something,
} >>>but have you considered the possibility that there is an LVM config
} >>>on the md array, and that the ext3 filesystem is inside a logical
} >>>volume?
} >>
} >>>NeilBrown
} >>
} >> Hi Neil, I already checked with western digital and its support team.
} What
} >> they've told me is that the Raid is an EXT3 and is not LVM config on
} the
} > HD,
} >> however knowing WD they might just say that so I'd fork over the cash
} to
} > get
} >> my HD recovered for thousands of dollars from them. Is there a way I
} can
} >> check if it's LVM config-ed? Thanks!
} >>
} >>
} >> --
} >> To unsubscribe from this list: send the line "unsubscribe linux-raid"
} in
} >> the body of a message to majordomo@vger.kernel.org
} >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
} >>
} >
} >
} >
} > --
} >       Majed B.
} >
} >
} 
} 
} 
} --
}        Majed B.
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

I actually know the physical order of each HD. I was able to pull them out
of the NAS in the order specified in the NAS. (Each HD enclosure was
labeled) In the actual sata ports, this is what the hds are in.

SATA 0: HD1
SATA 1: HD2
SATA 2: HD3
SATA 3: HD4
SATA 4: CD-ROM

I think that linux reads the sata ports like.. 0 = sda, 1=sdb.. etc. So I
assume that HD1 = /dev/sda (missing), HD2 = /dev/sdb, HD3 = /dev/sdc, HD4 =
/dev/sdd so a create command should look like this:

#mdadm -Cv -level=5 --raid-disks=4 missing /dev/sdb4 /dev/sdc4 /dev/sdd4

This is exactly how I wrote the create command. Again I knew the physical
order of the Raid and put them together in that order. Tell me if I'm doing
something wrong. 

I'll check out testdisk as well..

Thanks!

-----Original Message-----
From: Majed B. [mailto:majedb@gmail.com] 
Sent: Tuesday, September 22, 2009 8:14 PM
To: Sunpyo Hong
Cc: Robin Hill; linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

If you are sure that you have created the array with the proper order
of disks (They MUST be in the correct order! Your disks may have
changed their names for some reason -- verify that they are in
order!!) and that you have assembled them properly, I would suggest
you run a tool called "testdisk"

You may have a corrupt filesystem, and testdisk would try to fix it.
Also, to make sure that you have assembled the array in the correct
order, and if the filesystem can't be fixed if it's corrupt, use a
file-recovery tool like foremost or magicrescue and see if they
recover your data.

On Tue, Sep 22, 2009 at 9:42 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
> Nothing showed up when I did  "sudo lvscan". I'm pretty much stumped.
>
> -----Original Message-----
> From: Majed B. [mailto:majedb@gmail.com]
> Sent: Tuesday, September 22, 2009 11:24 AM
> To: Sunpyo Hong
> Cc: Robin Hill; linux-raid@vger.kernel.org
> Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.
>
> When the array is properly assembled, "sudo lvscan" should show any
> logical volumes. Maybe even without the array assembled.
>
> If nothing shows up, then you don't have an LV configured.
>
> On Tue, Sep 22, 2009 at 6:15 PM, Sunpyo Hong <sunpyo.hong@amac.com> wrote:
>>> I am stopping and starting the array. I couldn't mount in both
instances.
>>> The before is the initial assembly array that I force assembled through
>>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file
system.
>>
>>>I haven't followed all of this thread, so maybe I missed something,
>>>but have you considered the possibility that there is an LVM config
>>>on the md array, and that the ext3 filesystem is inside a logical
>>>volume?
>>
>>>NeilBrown
>>
>> Hi Neil, I already checked with western digital and its support team.
What
>> they've told me is that the Raid is an EXT3 and is not LVM config on the
> HD,
>> however knowing WD they might just say that so I'd fork over the cash to
> get
>> my HD recovered for thousands of dollars from them. Is there a way I can
>> check if it's LVM config-ed? Thanks!
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
>       Majed B.
>
>



-- 
       Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[John Robinson]

On 23/09/2009 14:56, Sunpyo Hong wrote:
> I actually know the physical order of each HD. I was able to pull them out
> of the NAS in the order specified in the NAS. (Each HD enclosure was
> labeled) In the actual sata ports, this is what the hds are in.
> 
> SATA 0: HD1
> SATA 1: HD2
> SATA 2: HD3
> SATA 3: HD4
> SATA 4: CD-ROM
> 
> I think that linux reads the sata ports like.. 0 = sda, 1=sdb.. etc. So I
> assume that HD1 = /dev/sda (missing), HD2 = /dev/sdb, HD3 = /dev/sdc, HD4 =
> /dev/sdd so a create command should look like this:
> 
> #mdadm -Cv -level=5 --raid-disks=4 missing /dev/sdb4 /dev/sdc4 /dev/sdd4
> 
> This is exactly how I wrote the create command. Again I knew the physical
> order of the Raid and put them together in that order. Tell me if I'm doing
> something wrong. 

If HD1 is really missing, and you've rebooted, then HD2 will now be sda, 
HD3 sdb, HD4 sdc, and your command is

#mdadm -Cv -level=5 --raid-disks=4 missing /dev/sda4 /dev/sdb4 /dev/sdc4

Cheers,

John.

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Wed Sep 23, 2009 at 09:56:52AM -0400, Sunpyo Hong wrote:

> I actually know the physical order of each HD. I was able to pull them out
> of the NAS in the order specified in the NAS. (Each HD enclosure was
> labeled) In the actual sata ports, this is what the hds are in.
> 
> SATA 0: HD1
> SATA 1: HD2
> SATA 2: HD3
> SATA 3: HD4
> SATA 4: CD-ROM
> 
> I think that linux reads the sata ports like.. 0 = sda, 1=sdb.. etc. So I
> assume that HD1 = /dev/sda (missing), HD2 = /dev/sdb, HD3 = /dev/sdc, HD4 =
> /dev/sdd so a create command should look like this:
> 
> #mdadm -Cv -level=5 --raid-disks=4 missing /dev/sdb4 /dev/sdc4 /dev/sdd4
> 
> This is exactly how I wrote the create command. Again I knew the physical
> order of the Raid and put them together in that order. Tell me if I'm doing
> something wrong. 
> 
> I'll check out testdisk as well..
> 
The array order detected by the initial --assemble is (unless you have
incredibly strong reason to believe otherwise) most likely to be the
correct order, in which case the correct create command should be:
    mdadm -Cv -l 5 -n 4 /dev/sdd4 /dev/sdc4 /dev/sdb4 missing

I'd suggest re-creating the array in this order (ignoring the irrelevant
"physical" ordering) before attempting any other recovery.
Incidentally, does the --create command report that any of the disks
contain an ext2/3 filesystem? This is usually reported for one of the
drives.

However, given that the initially-assembled array failed to mount, I
suspect you're hosed, and that whatever the ShareSpace did in attempting
to rebuild the array has actually broken it completely.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

I was also very confused because when running the --create command, none of
the disks reported that it did not contain an ext2/3 filesystem. What does
that mean? Because when I contacted WD they told me the system was an ext3
filesystem.

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
Sent: Wednesday, September 23, 2009 11:15 AM
To: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

On Wed Sep 23, 2009 at 09:56:52AM -0400, Sunpyo Hong wrote:

> I actually know the physical order of each HD. I was able to pull them out
> of the NAS in the order specified in the NAS. (Each HD enclosure was
> labeled) In the actual sata ports, this is what the hds are in.
> 
> SATA 0: HD1
> SATA 1: HD2
> SATA 2: HD3
> SATA 3: HD4
> SATA 4: CD-ROM
> 
> I think that linux reads the sata ports like.. 0 = sda, 1=sdb.. etc. So I
> assume that HD1 = /dev/sda (missing), HD2 = /dev/sdb, HD3 = /dev/sdc, HD4
=
> /dev/sdd so a create command should look like this:
> 
> #mdadm -Cv -level=5 --raid-disks=4 missing /dev/sdb4 /dev/sdc4 /dev/sdd4
> 
> This is exactly how I wrote the create command. Again I knew the physical
> order of the Raid and put them together in that order. Tell me if I'm
doing
> something wrong. 
> 
> I'll check out testdisk as well..
> 
The array order detected by the initial --assemble is (unless you have
incredibly strong reason to believe otherwise) most likely to be the
correct order, in which case the correct create command should be:
    mdadm -Cv -l 5 -n 4 /dev/sdd4 /dev/sdc4 /dev/sdb4 missing

I'd suggest re-creating the array in this order (ignoring the irrelevant
"physical" ordering) before attempting any other recovery.
Incidentally, does the --create command report that any of the disks
contain an ext2/3 filesystem? This is usually reported for one of the
drives.

However, given that the initially-assembled array failed to mount, I
suspect you're hosed, and that whatever the ShareSpace did in attempting
to rebuild the array has actually broken it completely.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

Needed some help with confirming something before I tried it. After
analyzing my /dev/md2 with Testdisk, I was able to see parts of the old
filesystem on my NAS! Very exciting seeing as I wasn't able to see anything
for the past month or so. However I don't see any of the important files in
any of the directory. It also seems to skip from 00% to 99% in seconds. This
can't be possible since my HD size is 5.5TBs. When trying "Deeper Search" an
error occurs and my raid fails. However when I recreate the raid, it's in a
clean-degraded condition. (Which it originally was since one of the disks is
missing.) I also get this saying:

"Partition sector doesn't have the endmark 0xAA55"

After reading around I heard that you're able to write a standard MBR and
that would fix this problem. Only thing is I'm worried that by writing a
standard MBR I would be deleting data.

Another error I get when running testdisk is I get a warning about the
geometry:

"Warning: the current number of heads per cylinder is 2 but the correct
value may be 32.
You can use the Geometry menu to change this value. It's something to try if
-Some partition are not found by testdisk"

I heard changing your geometry is something that can potentially make your
HDD unreadable, so I'm saving that for last. But any more clarifications on
this error or anything else would be appreciated. I think I'm close, but
this has been a long and arduous journey... Thanks.

-Sunpyo


-----Original Message-----
From: Majed B. [mailto:majedb@gmail.com] 
Sent: Tuesday, September 22, 2009 8:14 PM
To: Sunpyo Hong
Cc: Robin Hill; linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

If you are sure that you have created the array with the proper order
of disks (They MUST be in the correct order! Your disks may have
changed their names for some reason -- verify that they are in
order!!) and that you have assembled them properly, I would suggest
you run a tool called "testdisk"

You may have a corrupt filesystem, and testdisk would try to fix it.
Also, to make sure that you have assembled the array in the correct
order, and if the filesystem can't be fixed if it's corrupt, use a
file-recovery tool like foremost or magicrescue and see if they
recover your data.

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]

On Thu Sep 17, 2009 at 05:46:33PM -0400, Sunpyo Hong wrote:

> First off, lemme tell you the initial problem. I had a WD ShareSpace that
> had one of the disk go bad. They sent a replacement and it was suppose to
> rebuild on its own, however after the build, the array went bad and it was
> no longer able to see any of the files. 
> 
> I downloaded and tested the drives using windows data recovery tools I saw
> that the ext3 was Linux FS and that using these tools would not help in the
> recovery. However through the tools I was able to see and recover some of
> the files, but the files themselves were usable. I confirmed with WD that
> ext3 was in fact the FS and took steps to recover the data. These are the
> steps I took in order for me to assemble the raid.
> 
> Right now I have 3/4 drives with the data. I did #mdadm --assemble --scan,
> which let me assemble the raid. However at this point I was not able to see
> any of the files or mount the drive to the mount point it was once at. I
> have also tried #mdadm --create with the array in the right order /w the
> missing disk. 
> 
> Initially the --assemble --scan assembled the array /dev/md2 with the disks
> in the wrong order. I know because I physically saw where the disks were in
> relation to the disk order and wrote down the disk order on every HD.
> 
This should not be possible - --assemble will read the metadata from the
superblocks and determine the order the drives should be within the
array.  The physical positioning/ordering is irrelevant here.  I suggest
you recreate the array in the original order --assemble did (and hope
that the chunk size used is the default).

> #cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] 
> md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
>       5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
>       
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
>       208768 blocks [4/3] [UUU_]
>       
I find it somewhat odd that md0 and md2 have the drives in a different
order.  Is this related to your recreating the array?  Admittedly, md0
is only a RAID1 so the order doesn't actually matter, but if the arrays
were created at the same time then the normal behaviour would be to use
the same order in the create command.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

First off, lemme tell you the initial problem. I had a WD ShareSpace that
had one of the disk go bad. They sent a replacement and it was suppose to
rebuild on its own, however after the build, the array went bad and it was
no longer able to see any of the files. 

I downloaded and tested the drives using windows data recovery tools I saw
that the ext3 was Linux FS and that using these tools would not help in the
recovery. However through the tools I was able to see and recover some of
the files, but the files themselves were usable. I confirmed with WD that
ext3 was in fact the FS and took steps to recover the data. These are the
steps I took in order for me to assemble the raid.

Right now I have 3/4 drives with the data. I did #mdadm --assemble --scan,
which let me assemble the raid. However at this point I was not able to see
any of the files or mount the drive to the mount point it was once at. I
have also tried #mdadm --create with the array in the right order /w the
missing disk. 

Initially the --assemble --scan assembled the array /dev/md2 with the disks
in the wrong order. I know because I physically saw where the disks were in
relation to the disk order and wrote down the disk order on every HD.

Here's everything I could find in terms of information that you asked for.
It's a lot.

#dmesg
[  339.440187] raid5: device sdb4 operational as raid disk 1
[  339.440189] raid5: device sdd4 operational as raid disk 3
[  339.440192] raid5: device sdc4 operational as raid disk 2
[  339.440610] raid5: allocated 4219kB for md2
[  339.440612] raid5: raid level 5 set md2 active with 3 out of 4 devices,
algorithm 2
[  339.440615] RAID5 conf printout:
[  339.440617]  --- rd:4 wd:3
[  339.440619]  disk 1, o:1, dev:sdb4
[  339.440620]  disk 2, o:1, dev:sdc4
[  339.440622]  disk 3, o:1, dev:sdd4
[  339.440817]  md2: unknown partition table
[  538.840033] kjournald starting.  Commit interval 5 seconds
[  538.891844] EXT3 FS on md0, internal journal
[  538.891849] EXT3-fs: mounted filesystem with ordered data mode.
[  581.585031] VFS: Can't find ext4 filesystem on dev md2.
[  587.056825] VFS: Can't find ext3 filesystem on dev md2.


#fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk
doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      243202  1953514583+  ee  GPT

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e3

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdb2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdb3             157         182      208845   fd  Linux raid
autodetect
/dev/sdb4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdc2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdc3             157         182      208845   fd  Linux raid
autodetect
/dev/sdc4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xdd07e5e2

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1          26      208844+  fd  Linux raid
autodetect
/dev/sdd2              27         156     1044225   fd  Linux raid
autodetect
/dev/sdd3             157         182      208845   fd  Linux raid
autodetect
/dev/sdd4             183      243201  1952050117+  fd  Linux raid
autodetect

Disk /dev/md0: 213 MB, 213778432 bytes
2 heads, 4 sectors/track, 52192 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md2: 5996.6 GB, 5996697747456 bytes
2 heads, 4 sectors/track, 1464037536 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md2 doesn't contain a valid partition table


#cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
      5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      
md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
      208768 blocks [4/3] [UUU_]
      

#cat /etc/fstab
aufs / aufs rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0
/dev/sda2 swap swap defaults 0 0
/dev/sdb2 swap swap defaults 0 0
/dev/sdc2 swap swap defaults 0 0
/dev/sdd2 swap swap defaults 0 0


#mount -t ext3 /dev/md2 /media/disk/shares
mount: wrong fs type, bad option, bad superblock on /dev/md2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

#mdadm -Ds -v
ARRAY /dev/md0 level=raid1 num-devices=4 metadata=00.90
UUID=15e54255:f58be7ca:7f4a592f:038fedf2
   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md2 level=raid5 num-devices=4 metadata=00.90
UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
   devices=/dev/sdb4,/dev/sdc4,/dev/sdd4

#mdadm -Es -v
ARRAY /dev/md0 level=raid1 num-devices=4
UUID=15e54255:f58be7ca:7f4a592f:038fedf2
   devices=/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md1 level=raid1 num-devices=4
UUID=57cd5e76:0d56f114:50bd5336:4477d020
   devices=/dev/sdd2,/dev/sdc2,/dev/sdb2
ARRAY /dev/md2 level=raid5 num-devices=4
UUID=0b23d5e1:f5a27618:e368bf24:bd0fce41
   devices=/dev/sdd4,/dev/sdc4,/dev/sdb4

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Robin Hill
Sent: Thursday, September 17, 2009 5:02 PM
To: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Issue, cannot recognize EXT3 File system.

On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:

> I've contacted just about everyone that knows a thing about RAID5, but no
> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays
and
> how to properly assemble them. However I've run into a problem with a NAS
> system from WD that I just can't seem to figure out.
> 
> I have a ¾ disks in the array, 1 went down and is out of commission.  I've
> been able to assemble my array through mdadm using --assemble --scan.
However
> I cannot access the array due to the fact that the array cannot read a
> filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I
> know that the FS is an ext3 FS. However I cannot seem to get this
> thing going. I was wondering if anyone could point me in the right
> direction with this. I can't seem to find anyone that is capable of
> solving this. I would appreciate any help. Thanks!
> 
What's the output of 'cat /proc/mdstat' after you assemble the array?
And what exact error (and dmesg output) do you get when trying to mount
it as ext3?

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Majed B.]

This NAS from WD, does it use Linux's software RAID?
If not, you can't assemble it under Linux, because the RAID controller
is using proprietary methods.

On Fri, Sep 18, 2009 at 12:01 AM, Robin Hill <robin@robinhill.me.uk> wrote:
> On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:
>
>> I've contacted just about everyone that knows a thing about RAID5, but no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays and
>> how to properly assemble them. However I've run into a problem with a NAS
>> system from WD that I just can't seem to figure out.
>>
>> I have a ¾ disks in the array, 1 went down and is out of commission.  I've
>> been able to assemble my array through mdadm using --assemble --scan. However
>> I cannot access the array due to the fact that the array cannot read a
>> filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I
>> know that the FS is an ext3 FS. However I cannot seem to get this
>> thing going. I was wondering if anyone could point me in the right
>> direction with this. I can't seem to find anyone that is capable of
>> solving this. I would appreciate any help. Thanks!
>>
> What's the output of 'cat /proc/mdstat' after you assemble the array?
> And what exact error (and dmesg output) do you get when trying to mount
> it as ext3?
>
> Cheers,
>    Robin
> --
>     ___
>    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
>   / / )      | Little Jim says ....                            |
>  // !!       |      "He fallen in de water !!"                 |
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 5 Issue, cannot recognize EXT3 File system.

[Robin Hill]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Thu Sep 17, 2009 at 04:20:16PM -0400, Sunpyo Hong wrote:

> I've contacted just about everyone that knows a thing about RAID5, but no
> one is really able to help me. Anyhow I've read up a lot on RAID5 arrays and
> how to properly assemble them. However I've run into a problem with a NAS
> system from WD that I just can't seem to figure out.
> 
> I have a ¾ disks in the array, 1 went down and is out of commission.  I've
> been able to assemble my array through mdadm using --assemble --scan. However
> I cannot access the array due to the fact that the array cannot read a
> filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I
> know that the FS is an ext3 FS. However I cannot seem to get this
> thing going. I was wondering if anyone could point me in the right
> direction with this. I can't seem to find anyone that is capable of
> solving this. I would appreciate any help. Thanks!
> 
What's the output of 'cat /proc/mdstat' after you assemble the array?
And what exact error (and dmesg output) do you get when trying to mount
it as ext3?

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Raid 5 Issue, cannot recognize EXT3 File system.

[Sunpyo Hong]

I’ve contacted just about everyone that knows a thing about RAID5, but no
one is really able to help me. Anyhow I’ve read up a lot on RAID5 arrays and
how to properly assemble them. However I’ve run into a problem with a NAS
system from WD that I just can’t seem to figure out.

I have a ¾ disks in the array, 1 went down and is out of commission. I’ve
been able to assemble my array through mdadm using –assemble –scan. However
I cannot access the array due to the fact that the array cannot read a
filesystem. Everytime I try to mount I get mount: wrong fs type… etc. I know
that the FS is an ext3 FS. However I cannot seem to get this thing going. I
was wondering if anyone could point me in the right direction with this. I
can’t seem to find anyone that is capable of solving this. I would
appreciate any help. Thanks!

-Sunpyo

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html