On Wednesday November 20, slpratt@us.ibm.com wrote:
>
> 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?
Yes. When a drive is added to an array it gets a number which it
keeps for it's life in the array. This is completely separate from
the number that says what it's role in the array is. This number,
together with the set_uuid, forms the 'name' of the device as long as
it is part of the array. So there could well be holes in the
numbering of devices, but in general the set of numbers would be
fairly dense (max number of holes is max number of hot-spaces that you
have had in the array at any one time).
>
> >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.
Thanks. I think I did check that once, but then I changed things
again :-(
Actually, making utime a u64 makes this properly aligned again, but I
will group the u64s together at the top.
>
> >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.
Another possibility that I considered was a size in chunks, but
sectors is less confusing.
>
>
> >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.
Well, actually it is user-space which dynamically assigns a minor.
It then has the option of recording, possibly as a symlink in /dev, the
relationship between the 'name' of the array and the dynamically
assigned minor.
>
> >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.
... except to show that is is sufficient to meet the needs of users.
Thanks for your comments,
NeilBrown
-
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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:34 EST