On Tuesday October 23, dledford@xxxxxxxxxx wrote: > On Tue, 2007-10-23 at 19:03 -0400, Bill Davidsen wrote: > > John Stoffel wrote: > > > Why do we have three different positions for storing the superblock? > > > > > Why do you suggest changing anything until you get the answer to this > > question? If you don't understand why there are three locations, perhaps > > that would be a good initial investigation. > > > > Clearly the short answer is that they reflect three stages of Neil's > > thinking on the topic, and I would bet that he had a good reason for > > moving the superblock when he did it. > > I believe, and Neil can correct me if I'm wrong, that 1.0 (at the end of > the device) is to satisfy people that want to get at their raid1 data > without bringing up the device or using a loop mount with an offset. > Version 1.1, at the beginning of the device, is to prevent accidental > access to a device when the raid array doesn't come up. And version 1.2 > (4k from the beginning of the device) would be suitable for those times > when you want to embed a boot sector at the very beginning of the device > (which really only needs 512 bytes, but a 4k offset is as easy to deal > with as anything else). From the standpoint of wanting to make sure an > array is suitable for embedding a boot sector, the 1.2 superblock may be > the best default. > Exactly correct. Another perspective is that I chickened out of making a decision and chose to support all the credible possibilities that I could think of. And showed that I didn't have enough imagination. The other possibility that I should have included (as has been suggested in this conversation, and previously on this list) is to store the superblock both at the beginning and the end for redundancy. However I cannot decide whether to combine the 1.0 and 1.1 locations, or the 1.0 and 1.2. And I don't think I want to support both (maybe I've learned my lesson). As for where the metadata "should" be placed, it is interesting to observe that the SNIA's "DDFv1.2" puts it at the end of the device. And as DDF is an industry standard sponsored by multiple companies it must be ...... Sorry. I had intended to say "correct", but when it came to it, my fingers refused to type that word in that context. DDF is in a somewhat different situation though. It assumes that the components are whole devices, and that the controller has exclusive access - there is no way another controller could interpret the devices differently before the DDF controller has a chance. DDF is also interesting in that it uses 512 byte alignment for metadata. The 'anchor' block is in the last sector of the device. This contrasts with current md metadata which is all 4K aligned. Given that the drive manufacturers seem to be telling us that "4096 is the new 512", I think 4K alignment was a good idea. It could be that DDF actually specifies the anchor to reside in the last "block" rather than the last "sector", and it could be that the spec allows for block size to be device specific - I'd have to hunt through the spec again to be sure. For the record, I have no intention of deprecating any of the metadata formats, not even 0.90. It is conceivable that I could change the default, though that would require a decision as to what the new default would be. I think it would have to be 1.0 or it would cause too much confusion. I think it would be entirely appropriate for a distro (especially an 'enterprise' distro) to choose a format and location that it was going to standardise on and support, and make that the default on that distro (by using a CREATE line in mdadm.conf). Debian has already done this by making 1.0 the default. I certainly accept that the documentation is probably less that perfect (by a large margin). I am more than happy to accept patches or concrete suggestions on how to improve that. I always think it is best if a non-developer writes documentation (and a developer reviews it) as then it is more likely to address the issues that a non-developer will want to read about, and in a way that will make sense to a non-developer. (i.e. I'm to close to the subject to write good doco). NeilBrown - 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
