[opensuse-factory] /dev/md12X error messages bad?
http://fm.no-ip.com/Tmp/Linux/big41raidNADA.txt contains output from lsmod, cat /proc/mdstat, and tune2fs -l. Booted to 13.TW (or 13.2 or 13.1), I was hunting for a lost .iso file. The HD I thought it might be on is partitioned as a mirror of this system's 2 HDs that make up its 8 RAID1 devices. My (years old) marking on it made unclear as to whether I had only prepped its partitions for use as a backup HD, or had actually used it in this system and later replaced one with newer leaving this as an offline spare. For access, I tried to mount it to a different machine either via eSATA hotplug, or alternately as internal sdb. On boot (after doing modprobe raid1 after hotplug) /proc/mdstat showed devices as I would expect, except : all devices were "inactive", and 2: level was raid0, something I've never ever configured or used, having only used raid1 anywhere ever. 'tune2fs -l /dev/md120' reported tune2fs: Invalid argument while trying to open /dev/md120, and Couldn't find valid filesystem superblock In combination, the tune2fs and mdstat messages confused me. Had I never used this HD, and so really had no filesystems on its partitions? Was I forgetting something necessary to activate and access the md devices? Turns out the missing piece was absent /etc/mdadm.conf, which took a while to stumble onto, and the "backup" was too old to have what I was looking for. :-( But, are the messages I encountered expected? I thought with post-v0.9 md configuration, mdadm.conf wasn't supposed to be necessary. Isn't the tune2fs error misleading, or at least mislead by the unexpected inactive states? Is this experience due to the foreign host not having something in its initrd that this system includes? This one (11.4) loads raid0, raid1, raid10, raid456 and raid6_pq, while 13.TW/3.18.1 and 13.2/3.12 on the temp host show only raid1 loaded automatically (with SATA connection cold plug sdb). ??? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2015-01-07 08:56, Felix Miata wrote:
http://fm.no-ip.com/Tmp/Linux/big41raidNADA.txt contains output from lsmod, cat /proc/mdstat, and tune2fs -l.
My (years old) marking on it made unclear as to whether I had only prepped its partitions for use as a backup HD, or had actually used it in this system and later replaced one with newer leaving this as an offline spare.
md120 : inactive sdb14[0](S) 156280216 blocks super 1.0
Just a spare. (S) The array is also incomplete, i.e. you do not even have enough non-spare data volumes in your system to at least start it in degraded mode.
tune2fs: Invalid argument while trying to open /dev/md120, and Couldn't find valid filesystem superblock
Naturally, if the array is not even active, it reports zero size and e2fs won't find anything. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-01-07 09:13 (UTC+0100):
Felix Miata wrote:
http://fm.no-ip.com/Tmp/Linux/big41raidNADA.txt contains output from lsmod, cat /proc/mdstat, and tune2fs -l.
My (years old) marking on it made unclear as to whether I had only prepped its partitions for use as a backup HD, or had actually used it in this system and later replaced one with newer leaving this as an offline spare.
md120 : inactive sdb14[0](S) 156280216 blocks super 1.0
Just a spare. (S)
OK...
The array is also incomplete, i.e. you do not even have enough non-spare data volumes in your system to at least start it in degraded mode.
This I don't understand. Providing mdadm.conf and susequently being able to mount its md devices as /dev/mdX devices (ro, because degraded to one partition per device instead of 2 configured) seems to prove whatever needed to be wherever it needed to be was there, and the only problem had been lack of activation.
tune2fs: Invalid argument while trying to open /dev/md120, and Couldn't find valid filesystem superblock
Naturally, if the array is not even active, it reports zero size and e2fs won't find anything.
It doesn't seem natural to me to see the invalid argument message actually produced instead of something providing some kind of clue to an underlying problem. Apparently "couldn't find" is resulting from some different metadata location on the extX filesystem contained on the md devices, but won't find "anything" is just wrong. Surely there is recognizable stuff there somewhere or it wouldn't work after activation. Doesn't the existant partition type 0xFD provide e2fs a useful clue, or is maybe that what blinds it to what is actually present? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Wed, 07 Jan 2015 04:00:57 -0500
Felix Miata
Jan Engelhardt composed on 2015-01-07 09:13 (UTC+0100):
Felix Miata wrote:
http://fm.no-ip.com/Tmp/Linux/big41raidNADA.txt contains output from lsmod, cat /proc/mdstat, and tune2fs -l.
My (years old) marking on it made unclear as to whether I had only prepped its partitions for use as a backup HD, or had actually used it in this system and later replaced one with newer leaving this as an offline spare.
md120 : inactive sdb14[0](S) 156280216 blocks super 1.0
Just a spare. (S)
OK...
The array is also incomplete, i.e. you do not even have enough non-spare data volumes in your system to at least start it in degraded mode.
This I don't understand. Providing mdadm.conf and susequently being able to mount its md devices as /dev/mdX devices (ro, because degraded to one partition per device instead of 2 configured) seems to prove whatever needed to be wherever it needed to be was there, and the only problem had been lack of activation.
It would be helpful if you show mdadm.conf then.
Doesn't the existant partition type 0xFD provide e2fs a useful clue, or is maybe that what blinds it to what is actually present?
No. The only place where 0xfd partition type is (was) used is kernel-level Linux MD autodetection. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-01-07 12:17 (UTC+0300):
Wed, 07 Jan 2015 04:00:57 -0500 Felix Miata composed:
Jan Engelhardt composed on 2015-01-07 09:13 (UTC+0100):
Felix Miata wrote:
http://fm.no-ip.com/Tmp/Linux/big41raidNADA.txt contains output from lsmod, cat /proc/mdstat, and tune2fs -l.
My (years old) marking on it made unclear as to whether I had only prepped its partitions for use as a backup HD, or had actually used it in this system and later replaced one with newer leaving this as an offline spare.
md120 : inactive sdb14[0](S) 156280216 blocks super 1.0
Just a spare. (S)
OK...
The array is also incomplete, i.e. you do not even have enough non-spare data volumes in your system to at least start it in degraded mode.
This I don't understand. Providing mdadm.conf and susequently being able to mount its md devices as /dev/mdX devices (ro, because degraded to one partition per device instead of 2 configured) seems to prove whatever needed to be wherever it needed to be was there, and the only problem had been lack of activation.
It would be helpful if you show mdadm.conf then.
# uname -a Linux big41 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux # /etc/mdadm.conf DEVICE partitions ARRAY /dev/md0 level=raid1 UUID=7bb80bd1:7190763b:e67858c2:e1709118 ARRAY /dev/md1 level=raid1 UUID=30ea461c:9b926cd0:51ce856f:76aa6ff4 ARRAY /dev/md2 level=raid1 UUID=7e5708a2:0cf651d9:a76e1f13:a4a36c19 ARRAY /dev/md3 level=raid1 UUID=1af29bc5:ec2c3760:02daa1f0:5c28277a ARRAY /dev/md4 level=raid1 UUID=805ab730:c7ff1970:3aece583:fea16d3d ARRAY /dev/md5 level=raid1 UUID=fc3787e2:bc83c66c:8afe6288:1c75f7f0 ARRAY /dev/md6 level=raid1 UUID=cda6eba4:2d28ed19:bc1316ff:d7da2e59 ARRAY /dev/md7 level=raid1 UUID=f7939330:26ee7348:064baf79:480175e0
Doesn't the existant partition type 0xFD provide e2fs a useful clue, or is maybe that what blinds it to what is actually present?
No. The only place where 0xfd partition type is (was) used is kernel-level Linux MD autodetection.
"Was", as in kernel no long autodetects md devices? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2015-01-07 10:49, Felix Miata wrote:
# /etc/mdadm.conf DEVICE partitions ARRAY /dev/md0 level=raid1 UUID=7bb80bd1:7190763b:e67858c2:e1709118 ARRAY /dev/md1 level=raid1 UUID=30ea461c:9b926cd0:51ce856f:76aa6ff4 ARRAY /dev/md2 level=raid1 UUID=7e5708a2:0cf651d9:a76e1f13:a4a36c19 ARRAY /dev/md3 level=raid1 UUID=1af29bc5:ec2c3760:02daa1f0:5c28277a ARRAY /dev/md4 level=raid1 UUID=805ab730:c7ff1970:3aece583:fea16d3d ARRAY /dev/md5 level=raid1 UUID=fc3787e2:bc83c66c:8afe6288:1c75f7f0 ARRAY /dev/md6 level=raid1 UUID=cda6eba4:2d28ed19:bc1316ff:d7da2e59 ARRAY /dev/md7 level=raid1 UUID=f7939330:26ee7348:064baf79:480175e0
lsblk output, please.
Doesn't the existant partition type 0xFD provide e2fs a useful clue, or is maybe that what blinds it to what is actually present?
No. The only place where 0xfd partition type is (was) used is kernel-level Linux MD autodetection.
"Was", as in kernel no long autodetects md devices?
Old devices continue to be recognized, but with all the problems that can arise, contemoprary systems no longer recommend nor use kernel-level autodetection. This is now properly done in userspace instead. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Wed, 7 Jan 2015 11:32:28 +0100 (CET)
Jan Engelhardt
Doesn't the existant partition type 0xFD provide e2fs a useful clue, or is maybe that what blinds it to what is actually present?
No. The only place where 0xfd partition type is (was) used is kernel-level Linux MD autodetection.
"Was", as in kernel no long autodetects md devices?
Old devices continue to be recognized, but with all the problems that can arise, contemoprary systems no longer recommend nor use kernel-level autodetection.
In addition autodetection works with 0.90 metadata only, while all new installations default to 1.2. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2015-01-07 10:00, Felix Miata wrote:
md120 : inactive sdb14[0](S) 156280216 blocks super 1.0
tune2fs: Invalid argument while trying to open /dev/md120, and Couldn't find valid filesystem superblock
Naturally, if the array is not even active, it reports zero size and e2fs won't find anything.
It doesn't seem natural to me
It is how it is. $mdadm -C /dev/md0 -n 2 -l 1 -e 1.0 /dev/ram0 /dev/ram1 /dev/ram2 $mdadm /dev/md0 -a /dev/ram2 # add spare $mdadm -S /dev/md0 $mdadm -A /dev/md0 /dev/ram2 mdadm: /dev/md0 assembled from 0 drives and 1 spare - not enough to start the array. $blockdev --getsize64 /dev/md0 0 Alas, you can see from `mdadm -D /dev/md0` (or md120) that it is still State : inactive -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Andrei Borzenkov -
Felix Miata -
Jan Engelhardt