On Tue, Apr 21, 2009 at 08:34:01AM +0200, Gabor Gombas wrote:
On Mon, Apr 20, 2009 at 03:23:52PM +1000, Neil Brown wrote:
How does LVM manage metadata??? I assume it stored the metadata on
the device. Which is what mdadm does.
It stores a backup of the metadata under /etc after every changes it
makes. It is like if "mdadm --create" have automatically added the array
to /etc/mdadm.conf etc.
that could be interesting (automatically updating mdadm.conf on create,
maybe via an option)
But as devices can move between machines.....
With LVM, moving a volume group means running
vgchange/vgexport/pvscan/vgimport/vgchange, so it's not like "it just
works". So if there are any name conflicts, you must explicitely run
vgrename before the new VG can be activated.
yes, but vgexport/vgimport is optional, and the target audience for
array mobilit don't want to export the array before moving, they just
want to unplug it from a and replug into b.
> How about introducing /dev/md/by-uuid/... (or similar) and teaching
> people that if they want to transparently carry their arrays from one
> host to another, then they should always refer to it by UUID?
This already exists, though it might be distro-dependant.
/dev/disk/by-id/md-uuid-xxxxx
But that requrires the MD device to already be present therefore does
not help solving the name clash issue.
What I propose is that "mdadm --assemble" should accept "UUID=..."
instead of the MD device name. Then mdadm could ignore the
name/homehost, and create the device node with a name
(/dev/md/by-uuid/...) that will never clash with arrays using
traditional names.
i dont know how much we gain by hiding the md<minor> device, at least
while the kernel is not able to work completely without minors
see /proc/mdstat or /sys/block/md...
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
