Re: RAID6 issues

(stupid android mail client insists on top-posting - sorry)
No.  You cannot (easily) get that device to be an active member of
the array again, and it almost certainly wouldn't help anyway.

It would only help if the data you want is on the device, and the
parity blocks that are being used to recreate it are corrupt.
I think it very unlikely that they are corrupt but the data isn't.

The problem seems to be that the journal superblock is bad.  That seems
to suggest that much of the rest of the filesystem is OK.
I would suggest you "fsck -n -f" the device and see how much it wants
to 'fix'.  If it is just a few things, I would just let fsck fix it up for you.

If there are pages and pages of errors - then you have bigger problems.

NeilBrown


Andriano [off-list ref] wrote:

Still trying to get the array back up.

Status: Clean, degraded with 9 out of 10 disks.
One disk - removed as non-fresh.

as a result two of LVs could not be mounted:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg0-lv1,
     missing codepage or helper program, or other error
     In some cases useful info is found in syslog - try
     dmesg | tail  or so

mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg0-lv2,
     missing codepage or helper program, or other error
     In some cases useful info is found in syslog - try
     dmesg | tail  or so

[ 3357.006833] JBD: no valid journal superblock found
[ 3357.006837] EXT4-fs (dm-1): error loading journal
[ 3357.022603] JBD: no valid journal superblock found
[ 3357.022606] EXT4-fs (dm-2): error loading journal



Apparently there is a problem with re-adding non-fresh disk back to the array.

#mdadm -a -v /dev/md0 /dev/sdf
mdadm: /dev/sdf reports being an active member for /dev/md0, but a
--re-add fails.
mdadm: not performing --add as that would convert /dev/sdf in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sdf" first.

Question: Is there a way to resync the array using that non-fresh
disk, as it may contain blocks needed by these LVs.
At this stage I don't really want to add this disk as a spare.

Any suggestions please?


thanks

On Tue, Sep 13, 2011 at 8:44 PM, Andriano [off-list ref] wrote:

quoted

Thanks everyone, looks like the problem is solved.

For benefit of others who may experience same issue, here is what I've done:

- upgraded firmware on ST32000542AS disks - from CC34 to CC35. It must
be done using onboard SATA in Native IDE (not RAID/AHCI) mode.
After reconnecting them back to HBA, size of one of the offenders fixed itself!

- ran hdparm -N p3907029168 /dev/sdx command on other two disks and it
worked (probably it works straight after reboot)
Now mdadm -D shows the array as clean, degraded with one disk kicked
out, which is another story :)

now need to resync array and restore two LVs which hasn't mounted :(

On Tue, Sep 13, 2011 at 8:29 PM, Roman Mamedov [off-list ref] wrote:

quoted

On Tue, 13 Sep 2011 19:05:41 +1000
Andriano [off-list ref] wrote:

quoted

Connected one of the offenders to HBA port, and hdparm outputs this:

#hdparm -N /dev/sdh

/dev/sdh:
 max sectors   = 3907027055/14715056(18446744073321613488?), HPA
setting seems invalid (buggy kernel device driver?)

You could just try "hdparm -N p3907029168" (capacity of the 'larger' disks), but that could fail if the device driver is indeed buggy.

Another possible course of action would be to try that on some other controller.
For example on your motherboard you have two violet ports, http://www.gigabyte.ru/products/upload/products/1470/100a.jpg
those are managed by the JMicron JMB363 controller, try plugging the disks which need HPA to be removed to those ports, AFAIR that JMicron controller works with "hdparm -N" just fine.

--
With respect,
Roman

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