Raid 5 Issue, cannot recognize EXT3 File system.

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

I have a =BE disks in the array, 1 went down and is out of commission. =
I=92ve
been able to assemble my array through mdadm using =96assemble =96scan.=
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=85 etc.=
I know
that the FS is an ext3 FS. However I cannot seem to get this thing goin=
g. I
was wondering if anyone could point me in the right direction with this=
I
can=92t 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" i=
n
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.

--yEPQxsgoJgBvi8ip
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> I have a =BE 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. How=
ever
> 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=85 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!
>=20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--yEPQxsgoJgBvi8ip
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqyo7sACgkQShxCyD40xBI3bwCeN1IXfDn4FiUYlDgITkfo jxT1
ibYAn2+6dS/ek5Zj5dfxYmGYi9+mc2+9
=Q1GJ
-----END PGP SIGNATURE-----

--yEPQxsgoJgBvi8ip--
--
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.

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 wr=
ote:
> 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, b=
ut no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 ar=
rays 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 commis=
sion.  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â€=
=A6 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 mou=
nt
> it as ext3?
>
> Cheers,
>    Robin
> --
>     ___
>    ( ' }     |       Robin Hill =C2=
=A0       |
>   / / )      | Little Jim says ....    =
                    =
   |
>  // !!       |      "He fallen in =
de water !!"                 |
>



--=20
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

=46irst 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.=20

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 th=
at
ext3 was in fact the FS and took steps to recover the data. These are t=
he
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 --sc=
an,
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 th=
e
missing disk.=20

Initially the --assemble --scan assembled the array /dev/md2 with the d=
isks
in the wrong order. I know because I physically saw where the disks wer=
e 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 f=
or.
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 devic=
es,
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 fd=
isk
doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 4096 bytes
Disk identifier: 0x00000000

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


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

#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=3Draid1 num-devices=3D4 metadata=3D00.90
UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md2 level=3Draid5 num-devices=3D4 metadata=3D00.90
UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
devices=3D/dev/sdb4,/dev/sdc4,/dev/sdd4

#mdadm -Es -v
ARRAY /dev/md0 level=3Draid1 num-devices=3D4
UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md1 level=3Draid1 num-devices=3D4
UUID=3D57cd5e76:0d56f114:50bd5336:4477d020
devices=3D/dev/sdd2,/dev/sdc2,/dev/sdb2
ARRAY /dev/md2 level=3Draid5 num-devices=3D4
UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
devices=3D/dev/sdd4,/dev/sdc4,/dev/sdb4

-----Original Message-----
=46rom: 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, bu=
t no
> one is really able to help me. Anyhow I've read up a lot on RAID5 arr=
ays
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.
>=20
> I have a =BE 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=85 et=
c. 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!
>=20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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-----
=46rom: Sunpyo Hong [mailto:sunpyo.hong@amac.com]=20
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.

=46irst 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.=20

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 th=
at
ext3 was in fact the FS and took steps to recover the data. These are t=
he
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 --sc=
an,
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 th=
e
missing disk.=20

Initially the --assemble --scan assembled the array /dev/md2 with the d=
isks
in the wrong order. I know because I physically saw where the disks wer=
e 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 f=
or.
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 devic=
es,
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 fd=
isk
doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 16065 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 4096 bytes
Disk identifier: 0x00000000

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


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

#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=3Draid1 num-devices=3D4 metadata=3D00.90
UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md2 level=3Draid5 num-devices=3D4 metadata=3D00.90
UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
devices=3D/dev/sdb4,/dev/sdc4,/dev/sdd4

#mdadm -Es -v
ARRAY /dev/md0 level=3Draid1 num-devices=3D4
UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
ARRAY /dev/md1 level=3Draid1 num-devices=3D4
UUID=3D57cd5e76:0d56f114:50bd5336:4477d020
devices=3D/dev/sdd2,/dev/sdc2,/dev/sdb2
ARRAY /dev/md2 level=3Draid5 num-devices=3D4
UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
devices=3D/dev/sdd4,/dev/sdc4,/dev/sdb4

-----Original Message-----
=46rom: 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, bu=
t no
> one is really able to help me. Anyhow I've read up a lot on RAID5 arr=
ays
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.
>=20
> I have a =BE 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=85 et=
c. 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!
>=20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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 wr=
ote:
> 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) Thi=
s 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 suppos=
e to
> rebuild on its own, however after the build, the array went bad and i=
t 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 som=
e 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 w=
ere 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 secon=
ds
> [  538.891844] EXT3 FS on md0, internal journal
> [  538.891849] EXT3-fs: mounted filesystem with ordered data mod=
e.
> [  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 =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0x00000000
>
>   Device Boot      Start       =C2=
=A0 End      Blocks   Id  System
> /dev/sda1               1   =C2=
=A0  243202  1953514583+  ee  GPT
>
> Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e3
>
>   Device Boot      Start       =C2=
=A0 End      Blocks   Id  System
> /dev/sdb1               1   =C2=
=A0      26      208844+  fd  L=
inux raid
> autodetect
> /dev/sdb2              27   =C2=
=A0     156     1044225   fd  Linux raid
> autodetect
> /dev/sdb3             157    =
    182      208845   fd  Linux rai=
d
> 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 =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e4
>
>   Device Boot      Start       =C2=
=A0 End      Blocks   Id  System
> /dev/sdc1               1   =C2=
=A0      26      208844+  fd  L=
inux raid
> autodetect
> /dev/sdc2              27   =C2=
=A0     156     1044225   fd  Linux raid
> autodetect
> /dev/sdc3             157    =
    182      208845   fd  Linux rai=
d
> 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 =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e2
>
>   Device Boot      Start       =C2=
=A0 End      Blocks   Id  System
> /dev/sdd1               1   =C2=
=A0      26      208844+  fd  L=
inux raid
> autodetect
> /dev/sdd2              27   =C2=
=A0     156     1044225   fd  Linux raid
> autodetect
> /dev/sdd3             157    =
    182      208845   fd  Linux rai=
d
> 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 =3D cylinders of 8 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 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 err=
or
>       In some cases useful info is found in syslog - t=
ry
>       dmesg | tail  or so
>
> #mdadm -Ds -v
> ARRAY /dev/md0 level=3Draid1 num-devices=3D4 metadata=3D00.90
> UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md2 level=3Draid5 num-devices=3D4 metadata=3D00.90
> UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=3D/dev/sdb4,/dev/sdc4,/dev/sdd4
>
> #mdadm -Es -v
> ARRAY /dev/md0 level=3Draid1 num-devices=3D4
> UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
>   devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md1 level=3Draid1 num-devices=3D4
> UUID=3D57cd5e76:0d56f114:50bd5336:4477d020
>   devices=3D/dev/sdd2,/dev/sdc2,/dev/sdb2
> ARRAY /dev/md2 level=3Draid5 num-devices=3D4
> UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
>   devices=3D/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, b=
ut no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 ar=
rays
> 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 commis=
sion.  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â€=
=A6 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 mou=
nt
> it as ext3?
>
> Cheers,
>    Robin
> --
>     ___
>    ( ' }     |       Robin Hill =C2=
=A0       |
>   / / )      | 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.ht=
ml
>



--=20
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

--+xNpyl7Qekk2NvDX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.=20
>=20
> 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 t=
he
> 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.
>=20
> 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 s=
ee
> 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.=20
>=20
> Initially the --assemble --scan assembled the array /dev/md2 with the dis=
ks
> 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.
>=20
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]=20
> md2 : active raid5 sdb4[1] sdd4[3] sdc4[2]
> 5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
> =20
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
> 208768 blocks [4/3] [UUU_]
> =20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--+xNpyl7Qekk2NvDX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqzQRgACgkQShxCyD40xBLflgCcC9mzy3qqam4tXxZHEyMj ge7L
p5EAn19I7OgfuU1WjwPZNgQi3jQippBW
=V01v
-----END PGP SIGNATURE-----

--+xNpyl7Qekk2NvDX--
--
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.

Here's some more info:

Before
root@ubuntu:/home/ubuntu# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]=20
md2 : active raid5 sdb4[2] sdc4[1] sdd4[0]
5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
=20
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]=20
md2 : active raid5 sdd4[2] sdb4[1] sdc4[0]
5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
=20
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
[59137.800920] md: export_rdev(sdd4)
[59137.800961] md: unbind
[59137.804771] md: export_rdev(sdb4)
[59137.804778] md: unbind
[59137.804808] md: export_rdev(sdc4)
[59166.007689] md: bind
[59166.012173] md: bind
[59166.014076] md: bind
[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 devic=
es,
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-----
=46rom: Majed B. [mailto:majedb@gmail.com]=20
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 wr=
ote:
> 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) Thi=
s 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 suppos=
e to
> rebuild on its own, however after the build, the array went bad and i=
t 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 som=
e 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 w=
ere
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
> [ =A0339.440187] raid5: device sdb4 operational as raid disk 1
> [ =A0339.440189] raid5: device sdd4 operational as raid disk 3
> [ =A0339.440192] raid5: device sdc4 operational as raid disk 2
> [ =A0339.440610] raid5: allocated 4219kB for md2
> [ =A0339.440612] raid5: raid level 5 set md2 active with 3 out of 4 d=
evices,
> algorithm 2
> [ =A0339.440615] RAID5 conf printout:
> [ =A0339.440617] =A0--- rd:4 wd:3
> [ =A0339.440619] =A0disk 1, o:1, dev:sdb4
> [ =A0339.440620] =A0disk 2, o:1, dev:sdc4
> [ =A0339.440622] =A0disk 3, o:1, dev:sdd4
> [ =A0339.440817] =A0md2: unknown partition table
> [ =A0538.840033] kjournald starting. =A0Commit interval 5 seconds
> [ =A0538.891844] EXT3 FS on md0, internal journal
> [ =A0538.891849] EXT3-fs: mounted filesystem with ordered data mode.
> [ =A0581.585031] VFS: Can't find ext4 filesystem on dev md2.
> [ =A0587.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 =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0x00000000
>
> =A0 Device Boot =A0 =A0 =A0Start =A0 =A0 =A0 =A0 End =A0 =A0 =A0Block=
s =A0 Id =A0System
> /dev/sda1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0243202 =A019535145=
83+ =A0ee =A0GPT
>
> Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e3
>
> =A0 Device Boot =A0 =A0 =A0Start =A0 =A0 =A0 =A0 End =A0 =A0 =A0Block=
s =A0 Id =A0System
> /dev/sdb1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A026 =A0 =A0=
=A0208844+ =A0fd =A0Linux raid
> autodetect
> /dev/sdb2 =A0 =A0 =A0 =A0 =A0 =A0 =A027 =A0 =A0 =A0 =A0 156 =A0 =A0 1=
044225 =A0 fd =A0Linux raid
> autodetect
> /dev/sdb3 =A0 =A0 =A0 =A0 =A0 =A0 157 =A0 =A0 =A0 =A0 182 =A0 =A0 =A0=
208845 =A0 fd =A0Linux raid
> autodetect
> /dev/sdb4 =A0 =A0 =A0 =A0 =A0 =A0 183 =A0 =A0 =A0243201 =A01952050117=
+ =A0fd =A0Linux raid
> autodetect
>
> Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e4
>
> =A0 Device Boot =A0 =A0 =A0Start =A0 =A0 =A0 =A0 End =A0 =A0 =A0Block=
s =A0 Id =A0System
> /dev/sdc1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A026 =A0 =A0=
=A0208844+ =A0fd =A0Linux raid
> autodetect
> /dev/sdc2 =A0 =A0 =A0 =A0 =A0 =A0 =A027 =A0 =A0 =A0 =A0 156 =A0 =A0 1=
044225 =A0 fd =A0Linux raid
> autodetect
> /dev/sdc3 =A0 =A0 =A0 =A0 =A0 =A0 157 =A0 =A0 =A0 =A0 182 =A0 =A0 =A0=
208845 =A0 fd =A0Linux raid
> autodetect
> /dev/sdc4 =A0 =A0 =A0 =A0 =A0 =A0 183 =A0 =A0 =A0243201 =A01952050117=
+ =A0fd =A0Linux raid
> autodetect
>
> Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders
> Units =3D cylinders of 16065 * 512 =3D 8225280 bytes
> Disk identifier: 0xdd07e5e2
>
> =A0 Device Boot =A0 =A0 =A0Start =A0 =A0 =A0 =A0 End =A0 =A0 =A0Block=
s =A0 Id =A0System
> /dev/sdd1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A026 =A0 =A0=
=A0208844+ =A0fd =A0Linux raid
> autodetect
> /dev/sdd2 =A0 =A0 =A0 =A0 =A0 =A0 =A027 =A0 =A0 =A0 =A0 156 =A0 =A0 1=
044225 =A0 fd =A0Linux raid
> autodetect
> /dev/sdd3 =A0 =A0 =A0 =A0 =A0 =A0 157 =A0 =A0 =A0 =A0 182 =A0 =A0 =A0=
208845 =A0 fd =A0Linux raid
> autodetect
> /dev/sdd4 =A0 =A0 =A0 =A0 =A0 =A0 183 =A0 =A0 =A0243201 =A01952050117=
+ =A0fd =A0Linux raid
> autodetect
>
> Disk /dev/md0: 213 MB, 213778432 bytes
> 2 heads, 4 sectors/track, 52192 cylinders
> Units =3D cylinders of 8 * 512 =3D 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 =3D cylinders of 8 * 512 =3D 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]
> =A0 =A0 =A05856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [_=
UUU]
>
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
> =A0 =A0 =A0208768 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,
> =A0 =A0 =A0 missing codepage or helper program, or other error
> =A0 =A0 =A0 In some cases useful info is found in syslog - try
> =A0 =A0 =A0 dmesg | tail =A0or so
>
> #mdadm -Ds -v
> ARRAY /dev/md0 level=3Draid1 num-devices=3D4 metadata=3D00.90
> UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
> =A0 devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md2 level=3Draid5 num-devices=3D4 metadata=3D00.90
> UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
> =A0 devices=3D/dev/sdb4,/dev/sdc4,/dev/sdd4
>
> #mdadm -Es -v
> ARRAY /dev/md0 level=3Draid1 num-devices=3D4
> UUID=3D15e54255:f58be7ca:7f4a592f:038fedf2
> =A0 devices=3D/dev/sdd1,/dev/sdc1,/dev/sdb1
> ARRAY /dev/md1 level=3Draid1 num-devices=3D4
> UUID=3D57cd5e76:0d56f114:50bd5336:4477d020
> =A0 devices=3D/dev/sdd2,/dev/sdc2,/dev/sdb2
> ARRAY /dev/md2 level=3Draid5 num-devices=3D4
> UUID=3D0b23d5e1:f5a27618:e368bf24:bd0fce41
> =A0 devices=3D/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, b=
ut no
>> one is really able to help me. Anyhow I've read up a lot on RAID5 ar=
rays
> 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 =B5 disks in the array, 1 went down and is out of commissio=
n.
=A0I'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 mou=
nt
> it as ext3?
>
> Cheers,
> =A0 =A0Robin
> --
> =A0 =A0 ___
> =A0 =A0( ' } =A0 =A0 | =A0 =A0 =A0 Robin Hill =A0 =A0 =A0 =A0 obinhill.me.uk> |
> =A0 / / ) =A0 =A0 =A0| Little Jim says .... =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0// !! =A0 =A0 =A0 | =A0 =A0 =A0"He fallen in de water !!" =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 |
>
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

> Here's some more info:
>=20
> Before
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4]=20
> md2 : active raid5 sdb4[2] sdc4[1] sdd4[0]
> 5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
> =20
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
> 208768 blocks [4/3] [UUU_]
>=20
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 =3D> sdd
1 =3D> sdc
2 =3D> sdb

> Now.
> root@ubuntu:/home/ubuntu# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4]=20
> md2 : active raid5 sdd4[2] sdb4[1] sdc4[0]
> 5856150144 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
> =20
> md0 : active raid1 sdd1[0] sdb1[2] sdc1[1]
> 208768 blocks [4/3] [UUU_]
>=20
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
> [59137.800920] md: export_rdev(sdd4)
> [59137.800961] md: unbind
> [59137.804771] md: export_rdev(sdb4)
> [59137.804778] md: unbind
> [59137.804808] md: export_rdev(sdc4)
> [59166.007689] md: bind
> [59166.012173] md: bind
> [59166.014076] md: bind
> [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.
>=20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkq3oiQACgkQShxCyD40xBInvwCg2Dq9bu5rmlMUpJQZjSTe O1F0
upUAoKVaB5nZ9Lyky66O2ksY/FPjM0Kl
=a0qE
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--
--
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.

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
> [59137.800920] md: export_rdev(sdd4)
> [59137.800961] md: unbind
> [59137.804771] md: export_rdev(sdb4)
> [59137.804778] md: unbind
> [59137.804808] md: export_rdev(sdc4)
> [59166.007689] md: bind
> [59166.012173] md: bind
> [59166.014076] md: bind
> [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 |
/ / ) | 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.

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


--
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.

> 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

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 wro=
te:
>> I am stopping and starting the array. I couldn't mount in both insta=
nces.
>> The before is the initial assembly array that I force assembled thro=
ugh
>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file sy=
stem.
>
>>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.ht=
ml
>



--=20
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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

-----Original Message-----
=46rom: Majed B. [mailto:majedb@gmail.com]=20
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 wro=
te:
>> I am stopping and starting the array. I couldn't mount in both insta=
nces.
>> The before is the initial assembly array that I force assembled thro=
ugh
>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file sy=
stem.
>
>>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 =A0http://vger.kernel.org/majordomo-info.html
>



--=20
Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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 wro=
te:
> Nothing showed up when I did  "sudo lvscan". I'm pretty much stu=
mped.
>
> -----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 w=
rote:
>>> I am stopping and starting the array. I couldn't mount in both inst=
ances.
>>> The before is the initial assembly array that I force assembled thr=
ough
>>> mdadm -Af. This assembled the raid, but couldn't see an ext3 file s=
ystem.
>>
>>>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 cas=
h 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.h=
tml
>>
>
>
>
> --
>       Majed B.
>
>



--=20
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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 by=
te
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. M=
aybe
it was just a feature request. Not sure.

Anyway, mdadm supports "byteorder". man mdadm for more info. I have n=
ever
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.
}=20
} 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"
}=20
} 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.
}=20
} On Tue, Sep 22, 2009 at 9:42 PM, Sunpyo Hong w=
rote:
} > Nothing showed up when I did =A0"sudo lvscan". I'm pretty much stum=
ped.
} >
} > -----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
} 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 confi=
g
} >>>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 te=
am.
} 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 c=
ash
} 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-ra=
id"
} in
} >> the body of a message to majordomo@vger.kernel.org
} >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.ht=
ml
} >>
} >
} >
} >
} > --
} > =A0 =A0 =A0 Majed B.
} >
} >
}=20
}=20
}=20
} --
} 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" i=
n
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.

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 =3D sda, 1=3Dsdb.. etc=
So I
assume that HD1 =3D /dev/sda (missing), HD2 =3D /dev/sdb, HD3 =3D /dev/=
sdc, HD4 =3D
/dev/sdd so a create command should look like this:

#mdadm -Cv -level=3D5 --raid-disks=3D4 missing /dev/sdb4 /dev/sdc4 /dev=
/sdd4

This is exactly how I wrote the create command. Again I knew the physic=
al
order of the Raid and put them together in that order. Tell me if I'm d=
oing
something wrong.=20

I'll check out testdisk as well..

Thanks!

-----Original Message-----
=46rom: Majed B. [mailto:majedb@gmail.com]=20
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 wro=
te:
> Nothing showed up when I did =A0"sudo lvscan". I'm pretty much stumpe=
d.
>
> -----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 w=
rote:
>>> 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 thr=
ough
>>> 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 cas=
h 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 =A0http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> =A0 =A0 =A0 Majed B.
>
>



--=20
Majed B.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
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.

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.
--
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.

--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> SATA 0: HD1
> SATA 1: HD2
> SATA 2: HD3
> SATA 3: HD4
> SATA 4: CD-ROM
>=20
> I think that linux reads the sata ports like.. 0 =3D sda, 1=3Dsdb.. etc. =
So I
> assume that HD1 =3D /dev/sda (missing), HD2 =3D /dev/sdb, HD3 =3D /dev/sd=
c, HD4 =3D
> /dev/sdd so a create command should look like this:
>=20
> #mdadm -Cv -level=3D5 --raid-disks=3D4 missing /dev/sdb4 /dev/sdc4 /dev/s=
dd4
>=20
> 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 doi=
ng
> something wrong.=20
>=20
> I'll check out testdisk as well..
>=20
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
--=20
___ =20
( ' } | Robin Hill |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |

--qlTNgmc+xy1dBmNv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkq6O1sACgkQShxCyD40xBJK2wCeOlCnmemxlfBLC4zJFAGy +gEW
auwAn3WkVQembBP+RnetXYf7+zb+BhMp
=fH83
-----END PGP SIGNATURE-----

--qlTNgmc+xy1dBmNv--
--
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.

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 |
/ / ) | 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.

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.

--
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