(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 <chief000@xxxxxxxxx> 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 <chief000@xxxxxxxxx> wrote: >> 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 <rm@xxxxxxxxxx> wrote: >>> On Tue, 13 Sep 2011 19:05:41 +1000 >>> Andriano <chief000@xxxxxxxxx> wrote: >>> >>>> 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@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{����w��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
