Hi Matthew,
On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
> on disk:
> header:
> struct sa_phys {
> uint16_t sa_numattrs;
> struct {
> uint16_t sa_type; /* enum sssa_type */
> uint16_t sa_length; /* in sainfo[sa_type] chunks */
> } sssa_attr[];
> };
>
> followed by the data in the order specified by the header. 8-byte alignment
> will be enforced for all attribute starting offsets.
This would require repacking when adding an attribute, right? Anyway,
maybe that wouldn't be a big problem..
There's also the question of the attribute size limit.. from
conversations I had with Andreas, I got the feeling that the Lustre
layout information could be quite big when a file is striped through all
OSTs, and I would imagine this would become an even bigger concern in
the future if we intend to continue scaling horizontally.
Anyway, your proposal is interesting, but there's also one thing I would
like to add:
Could we have a special integer value that would essentially mean "this
is an unknown, name-value type of attribute", which would be used to
store additional, perhaps user-specified attributes?
In the space of the attribute value, we could store the name of the
attribute and the value itself (perhaps with 1 or 2 additional bytes for
the name length of the attribute).
These attributes could have lower priority than the other system
attributes (they would be stored at the end) and they would be ignored
(but not removed) by any implemention that doesn't understand them.
I also think that instead of having an additional block pointer (which
are huge) in the dnode for "spillage", we should have something like a
"uint64_t dn_spillobj" which would be an object id of a "spillage"
object.
An object id is much more space-efficient and, like Andreas mentioned,
allows for an unlimited number of attributes/attribute sizes.
I also find *extremely* appealing your idea of making this whole thing a
DMU service.
I think that would make our lives (as in Lustre developers' lives) much,
much easier in the long run.. the VFS dependencies in the ZPL code have
been kind of a pain, to say the least.. :)
Thanks,
Ricardo
--
Ricardo Manuel Correia
Lustre Engineering
Sun Microsystems, Inc.
Portugal
Phone +351.214134023 / x58723
Mobile +351.912590825
Email Ricardo.M.Correia at Sun.COM
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20080209/191da8da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6g_top.gif
Type: image/gif
Size: 1257 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20080209/191da8da/attachment.gif>
