FUSE extended attribute patches available

Kenneth D. Merry ken at FreeBSD.ORG
Tue Mar 1 15:11:19 UTC 2016


On Mon, Feb 29, 2016 at 19:02:28 -0500, Rick Macklem wrote:
> Ken Merry wrote:
> > I have patches for FreeBSD???s FUSE filesystem kernel module to support
> > extended attributes:
> > 
> > https://people.freebsd.org/~ken/fuse_extattr.20160229.1.txt
> > 
> > The patch implements the get/set/delete/list extended attribute methods.  The
> > listing code also converts extended attribute lists from the Linux/FUSE
> > format to the FreeBSD format.
> I also have patches, although my list didn't work. (I didn't know that there was
> a difference between what Linux/FUSE returns vs what FreeBSD wanted. So now I know
> why my "list" didn't work.)
> Btw, when I discussed what to do w.r.t. extended attribute namespace, he seemed to
> think just considering all the fuse ones as User was ok.

Ahh.  Who is "he" in this context?

It was easy enough to allow access to the user and system namespace.  FUSE
and Linux use the same names, so might as well pass them through.  The
other issue as far as FUSE goes, is that it is expecting the "user." or
"system." prefix on the attribute name.

FreeBSD passes those as a separate, numeric, argument in the VFS layer at
least, and expects to not see the namespace as a prefix when listing
attributes.

> I also have patched FreeBSD's Fuse for the other stuff needed to export the fuse
> mount via an NFS server. (VFS_FHTOVP() etc) These aren't quite ready for "prime time"
> but if anyone wants to try them, just email me and I'll send you a copy.
> 
> Btw, I have a couple of patches related to direct I/O and buffered I/O. You can
> find 2 of these at PR#206238. I also patched fuse_vnop_inactive() to flush/write
> dirty pages. (I think this is needed when an application mmaps a file and the
> modifies it after closing the file descriptor. I haven't actually tested to see
> if this fix is needed, so I haven't put it anywhere yet.)

Ahh, cool!  Now I can export a tape via NFS!  :)

Seriously, though, that will be helpful for some filesystems.

> >  For example:
> > 
> > # touch foo
> > # ls -la foo
> > -rwxrwxrwx  1 root  wheel  0 Feb 29 21:40 foo
> > # lsextattr user foo
> > foo
> > # setextattr user testattr1 "12345678" foo
> > # lsextattr user foo
> > foo     testattr1
> > # getextattr user testattr1 foo
> > foo     12345678
> > # setextattr user testattr2 "87654321" foo
> > # lsextattr user foo
> > foo     testattr2       testattr1
> > # rmextattr user testattr1 foo
> > # lsextattr user foo
> > foo     testattr2
> > # getextattr user testattr1 foo
> > getextattr: foo: failed: Attribute not found
> > # getextattr user testattr2 foo
> > foo     87654321
> > 
> > 
> > Just to be clear on what this does, it only provides extended attribute
> > support to FreeBSD applications if the underlying FUSE filesystem implements
> > FUSE extended attribute support.  Many FUSE filesystems don???t support the
> > extended attribute VFS operations.
> > 
> > I have tested this out on IBM???s LTFS implementation, but I have not yet found
> > another FUSE filesystem that supports extended attributes.  If anyone knows
> > of one, please let me know so I can try it out.  (I looked through a number
> > of the filesystems in sysutils/fusefs* in the ports tree.)
> > 
> The FreeBSD GlusterFS port includes a fuse interface that supports extended
> attributes. That is how I tested what I have. (I think the port is now in
> svn, but if not you can find the GlusterFS port at PR#194409.)
> It glusterfs.org doc doesn't mention that you can create/test a volume of
> only one brick, but that works for trivial testing. If you decide to use it
> for testing and have trouble getting it going, just email. I know diddly about
> GlusterFS, but I have fired it up a few times.

Ahh, that would be helpful.  I'll give it a try.

> > Any feedback is welcome.  I???m planning to check this into FreeBSD/head in the
> > next week or so.
> > 
> I'll try to get around and taking a look to see if there is anything different
> than what I did (other than the above "list" case I didn't get right;-).

Yes, it would be good to get another set of eyes.  Perhaps the namespace
handling (user versus system) is different as well.

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG


More information about the freebsd-fs mailing list