On 05/11/18 08:55, Xiao Ni wrote: > He can know when the disk is added through this item. If adding this item into > superblock, it needs to add a new super block version. Now the super1 block version > is 1.0 1.1 and 1.2. Maybe it needs to add 1.3 for this. Is it the right way to do > this? If using a new feature flag, it needs to specify a specific argument when > creating raid device. I'm not sure which way is better, or both are wrong? In theory, imho, this is all wrong. In practice, you may have to do it - depends how the 1.2 superblock is spec'd. Is there any "reserved for future use" space in 1.2? Is it explicitly zeroed? If so, you can just add your new field and say "if it's not zero, it's valid". That would be my preferred approach. If you update the superblock to v1.3, can I suggest you take a leaf from the book of variable length strings? One of the fields should be "structure length". That means you can then add as many fields as you like to the end of the struct without having to bump the number - it just means that any utility altering the struct needs to check either (a) is the struct bigger than the utility expects, in which case it needs to fail with "utility version too old", or (b) is the struct smaller than the utility expects, in which case it zeroes out the end of it and updates the length. Note also that v1.0, 1.1 and 1.2 are *identical* structs. So actually, you'd need to bump to v2.0 if you're adding a new field. The difference between .0, .1 and .2 is the *location* of the struct - .0 is at the end of the underlying partition, .1 at the beginning, and .2 is 4K from the start. Cheers, Wol
