On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote: > 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.
That is also one of things that I was concerned about. What do you think about providing an alternate interface in the nvlist code that would do an nvlist_lookup() without having to unpack the nvlist (ie, by searching the name directly in the encoded format)? The number of attributes on a file should be very limited so I don't think a linear search would be a problem. We could also provide a similar interface to add/update an attribute that would manipulate the encoded format directly (the XDR format looks fairly simple, I think). > As > part of this effort I would like to refactor the znode_phys to only > include what I believe to be the core attributes that must be in the > znode_phys. Then all of the secondary attributes that aren't needed all > of the time can use the new EA mechanisms that Lustre and others desire. > We will need to rev the ZPL version to 4. By refactoring the znode we > will recover a lot of the bonus space that is in short supply today. That sounds reasonable. > Section 2.2.4 > > Not sure what you mean by storing all xattrs in a single object? Are you > saying all of the Lustre attributes would be stored in a single Solaris > extended attribute file? Yes. The benefit of this approach is that it would greatly reduce the number of seeks (which are always in short supply) in a Lustre metadata server in the case where the xattrs won't fit in the dnode. > Section 2.2.5 > > This section is not needed. Solaris already has interfaces and > frameworks in place to expose additional attributes to applications. > Any attribute that lustre wants to retrieve/set can be retrieved with > VOP_GETATTR()/VOP_SETATTR() via the xvattr_t. From an application those > attributes can be manipulated with getattrat()/setattrat(). Are you referring to section 2.2.6 as opposed to 2.2.5? In Lustre, we are not using (nor we have the desire to use) any Solaris VFS code, so we can't use VOP_*() calls, vnode_t and/or znode_t structures (although we do manipulate znode_phys_t buffers), ACL code, etc.. Although we don't compile the majority of the ZPL code due to VFS dependencies, we do compile zfs_znode.c in userspace (without the _KERNEL definition). As you may understand, it would be very convenient for us if the core of this functionality would be free of VFS dependencies so that we could just implement a thin wrapper in our Lustre code. However, since this probably belongs more in the ZPL than in the DMU, it could be implemented in zfs_znode.c. Thanks! -- 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/20080207/433e375b/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/20080207/433e375b/attachment.gif>
