Neil Brown wrote; >I would like to propose a new layout, and to receive comment on it.. >/* constant this-device information - 64 bytes */ >u64 address of superblock in device >u32 number of this device in array /* constant over reconfigurations */ Does this mean that there can be holes in the numbering for disks that die and are replaced? >u32 device_uuid[4] >u32 pad3[9] >/* array state information - 64 bytes */ >u32 utime >u32 state /* clean, resync-in-progress */ >u32 sb_csum These next 2 fields are not 64 bit aligned. Either rearrange or add padding. >u64 events >u64 resync-position /* flag in state if this is valid) >u32 number of devices >u32 pad2[8] >Other features: >A feature map instead of a minor version number. Good. >64 bit component device size field. Size in sectors not blocks please. >no "minor" field but a textual "name" field instead. Ok, I assume that there will be some way for userspace to query the minor which gets dynamically assigned when the array is started. >address of superblock in superblock to avoid misidentifying superblock. e.g. is it >in a partition or a whole device. Really needed this. >The interpretation of the 'name' field would be up to the user-space >tools and the system administrator. Yes, so let's leave this out of this discussion. EVMS 2.0 with full user-space discovery should be able to support the new superblock format without any problems. We would like to work together on this new format. Keep up the good work, Steve - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html