>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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/