lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <568B7EA7.9010901@gmail.com>
Date:	Tue, 5 Jan 2016 11:28:23 +0300
From:	Andrei Borzenkov <arvidjaar@...il.com>
To:	linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Reading the same block via partition and non-partitioned device gives
 different content

[Please Cc me on reply; thank you]

QEMU KVM virtual machine with openSUSE Tumbleweed (kernel
4.3.3-3-default); MD RAID1 with 1.2 metadata on /dev/vdb1 and /dev/vdc1.

If I do

mdadm /dev/mdX --fail /dev/vdb1
mdadm /dev/mdX --add /dev/vdd1

and wait for synchronization to finish and then look directly on on-disk
suportblock, I see different content whether I read from /dev/vdd or
from /dev/vdd1.

/dev/vdd1 claims new disk is still spare (i.e. it is apparently
immediately after adding it).

The *same* superblock when read from /dev/vdd (of course with
appropriate offset) correctly marks /dev/vdd1 as RAID member. The same
content also seen when looking from host.

I hit this when debugging problem with grub2 that scans devices for
Linux MD (it is using the same code both at boot and run time). It
skipped replacement disk because it believed disk was spare.

Is it expected behavior? Note that if we now replace /dev/vdc1 with
something else we have "wrong" superblock on both partitions so grub
fails to find array completely. Fortunately this is transient state, but
it also means it is impossible to reconfigure grub until reboot.
Alternatively shutting down and restarting array cleats it as well.

Any trick we can use to force content to be the same in this state?

-andrei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ