Page MenuHomeFreeBSD

Add extended attribute support to fuse.
Needs ReviewPublic

Authored by rmacklem on Dec 21 2015, 11:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 21, 11:09 AM
Unknown Object (File)
Thu, Apr 18, 10:34 AM
Unknown Object (File)
Tue, Apr 16, 7:12 AM
Unknown Object (File)
Mon, Apr 15, 1:53 AM
Unknown Object (File)
Dec 22 2023, 11:37 PM
Unknown Object (File)
Nov 13 2023, 12:11 PM
Unknown Object (File)
Oct 25 2023, 8:19 AM
Unknown Object (File)
Oct 20 2023, 4:50 PM
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

This patch adds support for the extended attribute operations to fuse.

Test Plan

It has been tested minimally with GlusterFS.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

rmacklem retitled this revision from to Add extended attribute support to fuse..
rmacklem updated this object.
rmacklem edited the test plan for this revision. (Show Details)
rmacklem set the repository for this revision to rS FreeBSD src repository - subversion.

This patch adds extended attribute support to fuse. I need access
to some extended attributes in GlusterFS for my pNFS server work.
I don't know if any other fuse file systems support extended attributes?

For what it's worth, this patch seems to work when used with the net/s3ql filesystem. It has a unique method of communicating with the running daemon: it gets/sets extended attributes on a hidden control file in the mounted filesystem.

I've added Ken, since he also had a patch that added extended attribute support to fuse.
His patch actually worked for the "lsextattr" case, which is broken in this one.
The debate was that his patch prepended "system." or "user." to the extended
attribute name. That didn't work for my GlusterFS case, since it had extended
attribute names that didn't start with "system." or "user.".

Dan, does your filesystem use attribute names that start in "system." or "user."?

A compromise might be to prepend "user." for the NAMESPACE_USER, but leave
the names as specified for NAMESPACE_SYSTEM?

I've added Ken, since he might be interested in resurrecting his patch or maybe
we can merge them?

Dan, does your filesystem use attribute names that start in "system." or "user."?

Looking at the s3ql server code, it seems to expect unprefixed names for its control operations, but does have checks for specific names in the system namespace ( https://bitbucket.org/nikratio/s3ql/src/release-2.22/src/s3ql/fs.py#fs.py-201 ). So I'd say that it currently expects the control attribute names to not be prefixed with "user." .

The linux manpages seem to imply that namespaces are required, though ( "Attribute names are null-terminated strings. The attribute name is always specified in the fully qualified namespace.attribute form" ), so it sounds like there's insufficient validation in the Linux kernel, and the s3ql code is currently relying on undefined behaviour. It looks like s3ql could easily be patched to move those into the user namespace if necessary.

I've added Ken, since he also had a patch that added extended attribute support to fuse.
His patch actually worked for the "lsextattr" case, which is broken in this one.
The debate was that his patch prepended "system." or "user." to the extended
attribute name. That didn't work for my GlusterFS case, since it had extended
attribute names that didn't start with "system." or "user.".

Dan, does your filesystem use attribute names that start in "system." or "user."?

A compromise might be to prepend "user." for the NAMESPACE_USER, but leave
the names as specified for NAMESPACE_SYSTEM?

I've added Ken, since he might be interested in resurrecting his patch or maybe
we can merge them?

Sure, I have added a new Differential revision, D11827 with patches against FreeBSD/head from August 1st.

Merging is fine with me. You can take a look through it and see what you think.