On Fri, 09 Jan 2009 10:45:56 +0000, "John Robinson" <john.robinson@xxxxxxxxxxxxxxxx> said: > On 09/01/2009 02:41, whollygoat@xxxxxxxxxxxxxxx wrote: > > But anyway, I don't think that is going to matter. The issue I am > > trying to > > solve is how to de-activate the bitmap. It was suggested on the > > linux-raid > > list that my problem may have been caused by running the grow op on an > > active > > bitmap and I can't see from "man mdadm" how to de-activate the bit map. > > man mdadm tells me: > [...] > -b, --bitmap= > Specify a file to store a write-intent bitmap in. The file should > not exist unless --force is also given. The same file should be provided > when assembling the array. If the word internal is given, then the > bitmap is stored with the metadata on the array, and so is replicated on > all devices. If the word none is given with --grow mode, then any bitmap > that is present is removed. > > So I imagine you'd want to > # mdadm --grow /dev/mdX --bitmap=none > to de-activate the bitmap. The question that came to mind when I read that in the docs, was how to recreate the bitmap on an already created array after nuking it with "none". I guess I also had doubts because the reply I had a few iterations back didn't say that I shouldn't have performed the grow operation on an existant bitmap, but an active one, and I wasn't prepared to make the leap from active/inactive to existant/non-existant. But, this has all become moot anyway. When I put the original, smaller drives back in, hoping to do the grow op overagain, I was faced with a similar problem assembling the array, so I'm guessing the problem caused by something other than the grow. I put the larger drives in, zeroed them, and am in the process of recreating the array and file systems to be populated from backups. Thanks for the input. goat -- whollygoat@xxxxxxxxxxxxxxx -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow -- 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
