To put the document in a better perspective: The extended attributes (EAs), as we(Lustre) see, are the lighter weighted extended attributes which are user defined and user can be Beagle, Metatracker, Lustre etc. Lustre has been using the extended attributes http://acl.bestbits.at/about.html where ldiskfs (ext3 modified for Lustre) is used as backend. The design posted specifically tries to devise a similar mechanism for ZFS where even pNFS, MAC OS/X could possibly exploit this mechanism. Thus it also implies, Matt has already mentioned this, that the proposal made by him (Matt) for system attributes is not applicable.
As we do not intend to extend the current optional attributes i.e. struct xoptattr, the current APIs VOP_GETATTR/VOP_SETATTR won't serve the purpose. Hence the proposal of new APIs in section 2.2.5 of design doc. Use of existing APIs VOP_GETATTR/VOP_SETATTR will be possible if we somehow integrate the (userdefined) extended attributes with existing xoptattr_t. On Fri, 2008-02-08 at 11:48 -0800, Matthew Ahrens wrote: > Not as I read it. Solaris extended attributes will continue to be stored as > they are today -- as separate files in an xattr directory hung of the main > file. We have been discussing to move only uint8_t xoa_av_scanstamp[AV_SCANSTAMP_SZ], at least as of now, to nvlist which holds EAs in dnode, as the first 32 bytes just after the znode_phys are used by it. > The proposal is for some new system-interpreted attributes to be stored in > the dnode. This is a different namespace with different requirements and > different semantics. You don't need to set an ACL on your lustre metadata, > do you? > P.S. Couldn't reply early as I was down with high temperature and had been coughing my lungs out for past few days. -Girish
