From 148acb7baaa810b68d55df4c1784d6bd0dfd1b78 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Fri, 31 Jul 2009 17:11:41 -0700 Subject: imsm: fix family number handling The family_number field can change. The option-rom will change the family number when it starts a rebuild process (flags a container for rebuild). This was not seen previously as mdadm would usually start the rebuild process, preserving the family number. This is the mechanism that helps to prevent a prodigal array member from being returned to its original system and cause a rebuild to go in the wrong direction. With the change we will end up with a container that will fail to assemble unless the device with the incompatible family number is left out of the assembly. So, take several actions: 1/ Convert uuid generation to use orig_family_num, being careful to preserve the existing uuid in the case where orig_family_num is not set (i.e. previous mdadm created imsm arrays) 2/ Set orig_family_num at Create. For arrays created by mdadm prior to this release orig_family_num will be zero, so set it to family_num at the first metadata write. 3/ Add checks for orig_family_num to compare_super_imsm 4/ Update the family number when initiating rebuild 5/ The option-rom mixes some random data into the family number, add this functionality to the mdadm implementation. Reported-by: Marcin Labun Signed-off-by: Dan Williams --- util.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'util.c') diff --git a/util.c b/util.c index 00bf803..2543971 100644 --- a/util.c +++ b/util.c @@ -1298,6 +1298,17 @@ int check_env(char *name) return 0; } +__u32 random32(void) +{ + __u32 rv; + int rfd = open("/dev/urandom", O_RDONLY); + if (rfd < 0 || read(rfd, &rv, 4) != 4) + rv = random(); + if (rfd >= 0) + close(rfd); + return rv; +} + #ifndef MDASSEMBLE int flush_metadata_updates(struct supertype *st) { -- cgit