Andreas writes:
>
> Hi again,
>
>
> There were some good arguments for adding a few more features to the EA
> interface. This new proposal reflects some of the discussion.
>
> I still decline to support forks/streams through the EA interface. IMHO
> that's just the wrong way to go. This doesn't preclude an EA
> implementation on top of streams, of course.
>
> The interface described here also doesn't include Stephen's idea to allow
> an ordered list of EA's under the same name. In addition to the append and
> prepend operations Stephen suggested, a whole range of other operations
> (get/delete/... by index, etc.) might make sense, and stuff like that
> could well be added. However, it would complicate the semantics even
> further. I'd really like to learn more about the requirements for that.
>
Back to comments from the XFS team and your 2nd proposed API.
* We (XFS) also have an attr_multi() system call which is reminiscent of
your sys_ext_attr_XXX() call. It allows one to apply an op
to many attributes in the one call. However, it actually takes
an op-list, and thus can actually apply different ops to different
attributes in the one syscall, instead of taking the one op-code
as a parameter .
i.e. it takes: attr_multiop_t *oplist,
where
struct attr_multiop {
int am_opcode; /* which operation to perform (see below) */
int am_error; /* [out arg] result of this sub-op (an errno) */
char *am_attrname; /* attribute name to work with */
char *am_attrvalue; /* [in/out arg] attribute value (raw bytes) */
int am_length; /* [in/out arg] length of value */
int am_flags; /* flags (bit-wise OR of #defines above) */
};
opcode = ATTR_OP_GET, ATTR_OP_SET, ATTR_OP_REMOVE
The attr_multi() call does not actually provide atomicity
over the call - other threads could change the attributes between ops.
It also does not provide a log transaction for the set of ops.
So, I think it is just saving on multiple system calls.
It doesn't have a matching VOP call, it just calls the VOPS for
get, set and remove.
The only use I've seen in the IRIX tree is where the opcode is
the same for the given list -
i.e. 1 multi for setting a bunch of attributes and another
multi for getting a bunch of attributes
This could thus be achieved with your API.
* I noticed how you have Stephen's "attrib family" encoded as a
"namespace" in your API BUT I didn't see how you've encoded
Stephen's "name family" field.
BTW, I still don't have a clear understanding of the "name family".
Is it like some sort of "typing" for names ?
* As mentioned previously, we'd also like a way of optionally
following symlinks - such as by another flag value or another
system call variant.
* FYI our attr_list cursor is of the form:
<hashval: 32, blkno: 32, offset:32, initted: 8, pad: 24>
(instead of a single 32 bit offset).
The <hashval, offset> identifies which entry we were last at.
One form of the attribute data storage, actually stores
with ordered hashed-name entries and so the offset is used
to distinguish between equal hash values.
In another EA storage form, we don't actually
store the hash values, however, the list function still
preserves hash-value ordering and so we actually compute the
names' hash values.
I think the blkno is used in the BTREE form of storage as
a suggestion on where to start looking for the <hashval, offset>.
If it finds that the block isn't an EA block or it doesn't have
hash values in the right range then we start from the top of
the tree and search looking for <hashval, offset>.
The initted field is a 1 bit field (0/1) which says whether
the cursor has been initialized yet.
I can only see a test for it in the one place, which seems
to be just an early sanity test in xfs_attr_list()
if ((cursor->initted == 0) &&
(cursor->hashval || cursor->blkno || cursor->offset)) {
return(XFS_ERROR(EINVAL));
}
Sorry for the rambling :)
--Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
