On Mon, 08 Oct 2012 18:32:16 +0200 Sebastian Riemer <sebastian.riemer@xxxxxxxxxxxxxxxx> wrote: > Hi Neil, > > I must have overseen your answer. We want to use as less mdadm as > possible - especially for simple checking stuff. The kernel knows best. Kernel sometimes knows. Some arrays have metadata handled by user-space so the kernel wouldn't be able to report anything. Userspace always knows.. > "mdadm -D" reads the data from disk. This means additional disk access. > It is also possible that this command triggers superblock updates. > Simple checking stuff shouldn't have to use disk access. In that case, how about using /run/mdadm/map ?? When mdadm assembles an array it needs to know the uuid, and it records this in that file for future reference. Will that do? > > We are planning to use MD RAID a little bit different with e.g. 100 MD > arrays. Searching for a particular UUID in this bunch of MD devices can > be difficult without this patch. This is how the kernel represents > UUIDs. Conversion can be done in user space. I believe that format is for RFC4122 UUIDs. MD's UUIDs are not created according to those rules, so it isn't really appropriate to make it look like they were. However the formatting isn't the big issue - the UUID is something the kernel knows by accident more than by necessity. I'd rather it didn't. > > If you like it better in the xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx format, > I can resend the patch in that format. > > It simplifies our checking magic not to rely on udev symlinks and to ask > the kernel for the cached UUID. > > Btw.: We did an "Assemble-Resize-Stop, Assemble-Resize-Stop, ..."-Test > with "--assume-clean" and the second resize doesn't work. With > "Assemble-Resize-Detail-Stop" it works. More details? What exactly do you mean by "Resize"? What exactly do you mean by "doesn't work"? Can you make a simple script that reproduces this? If so, I'd love to see it. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
