On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
On Sat, 2007-10-20 at 09:53 +0200, Iustin Pop wrote:
Honestly, I don't see how a properly configured system would start
looking at the physical device by mistake. I suppose it's possible, but
I didn't have this issue.
Mount by label support scans all devices in /proc/partitions looking for
the filesystem superblock that has the label you are trying to mount.
it could probably be smarter, but in any case there is no point in
mounting by label an md device.
LVM (unless told not to) scans all devices in /proc/partitions looking
yes, but lvm unless told to, will ignore devices having a valid md
superblock.
for valid LVM superblocks. In fact, you can't build a linux system that
is resilient to device name changes without doing that.
i dislike labels, especially for devices that contain the os. we should
ensure great care that these are identified correctly, and
mount-by-label does not (usb drive that migrate from one system to
another are so common that you can't ignore them)
you forgot udev ;)
but the fix is easy.
remove the partition detection code from the kernel and start working on
a smart userspace replacement for device detection. we already have
vol_id from udev and blkid from ext3 which support detection of many
device formats.
just apply some rules, so if you find a partition table _AND_ an md
superblock at the end, read both and you can tell if it is an md on a
partition or a partitioned md raid1 device.
And you can with superblock at the front. You can create a new single
disk raid1 over the existing superblock or you can munge the partition
table to have it point at the start of your data. There are options,
Please don't do that,
use device-mapper to set the device up, without mucking with partition
tables.
L.
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
-
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
