Matthew Ahrens wrote:
> Mark Shellenbaum wrote:
>> Girish Shilamkar wrote:
>>> Hi,
>>> With reference to my previous mail ([zfs-code] Nvpair for storing EAs
>>> in dnode) which had expressed our intent to use libnvpair for EAs in
>>> dnode. I am now sending a high level design document for the same.
>>>
>>> Any suggestions/comments are most welcome.
>>>
>>> Thanks & Regards,
>>> Girish
>> General comment:
>>
>> I'm not sure we should be using nvlists to store these attributes.
>> While it will be quick to implement, I'm concerned about the constant
>> packing/unpacking and searching linked lists in the nvlist code.
>
> Agreed. Here is one proposal for how this could be done efficiently and
> scalably (both in space and runtime):
>
> First, note that the problem is quite constrained:
>
> There are a fixed number of attribute names (for any given software version)
> since these are interpreted system attributes. Therefore the attribute names
> can be a small number, rather than a string -- ie, we have an enum that
> defines the attributes. We (ie, OpenSolaris) can control the allocation of
> new enum values in this namespace.
>
> Many attributes will always have a fixed size (eg, scanstamp, finder info)
>
> Removing attributes or changing their sizes will be extremely rare, so we can
> make this code path slow. For example, it would not be prohibitive to repack
> & rewrite all attrs.
>
> Here is an idea for an on-disk format which takes advantage of these
> constraints to achieve good performance:
>
> (sa == System Attribute)
>
> enum sa_type {
> ST_ATIME,
> ST_ACL,
> ST_FINDERINFO,
> ST_SCANSTAMP,
> ST_LUSTRE_LAYOUT,
> ...
> ST_NUMTYPES
> };
>
> const struct sa_info {
> uint8_t sai_intlen;
> } sainfo = {
> 8, 2, 8, 8, 1, ...
> };
>
> 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[];
> };
>
I like this approach much better. I was thinking about some sort of
indexed table with attributes having a number to identify them rather
than a name. This will also allow us to kick out a number of the ZPLs
attributes into sa space, and then we can choose which additional
attributes need to be exposed with the Solaris sysattr framework.
-Mark
