FUSE extended attribute patches available

[Rick Macklem]

Kenneth D. Merry wrote:
> 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?
> 
rwatson@

> 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.
> 
Well, the extended attributes I am interested in are generated automagically
by GlusterFS and they don't have a "user." or "system." prefix.
For example: glusterfs.gfid

This wouldn't work if fuse prepended the "user." or "system.".

> 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.
> 
Btw, I have also done VOP_ADVLOCK(), since GlusterFS supports that.

> > >  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.
> 
Yep, as above, the "namespace" is an issue.

Have fun with it, rick

> Ken
> --
> Kenneth Merry
> ken at FreeBSD.ORG
>