On Thu, 2019-07-25 at 12:10 -0700, Gregory Farnum wrote:
> On Thu, Jul 25, 2019 at 12:04 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote:
> > On Thu, Jul 25, 2019 at 4:59 AM David Disseldorp <ddiss@xxxxxxx> wrote:
> > > On Thu, 25 Jul 2019 07:17:11 -0400, Jeff Layton wrote:
> > >
> > > > Yeah, I rolled a half-assed xfstests patch that did this, and HCH gave
> > > > it a NAK. He's probably right though, and fixing it in ceph.ko is a
> > > > better approach I think.
> > >
> > > It sounds as though Christoph's objection is to any use of a "ceph"
> > > xattr namespace for exposing CephFS specific information. I'm not sure
> > > what the alternatives would be, but I find the vxattrs much nicer for
> > > consumption compared to ioctls, etc.
> >
> > Agreed. I don't understand the objection [1] at all.
> >
> > If the issue is that utilities copying a file may also copy xattrs, I
> > don't understand why there would be an expectation that all xattrs are
> > copyable or should be copied.
>
> I'm sure it is about this, and that's the expectation because, uh,
> outside of weird things like Ceph then all matters are copyable and
> should be copied. That's how the interface is defined and built.
>
> I'm actually a bit puzzled to see this patch go by because I didn't
> think we listed the ceph.* matters on a listxattr command! If we want
> discoverability (to see what options are available on a running
> system) we can return them in response to a getxattr on the "ceph"
> xattr or something.
Yeah, that would be better, I think. For the record, ceph-fuse seems to
also report these via listxattr. Testing with a build as of this
morning:
$ strace -e listxattr -f -s 256 getfattr -m '.' scratch
listxattr("scratch", NULL, 0) = 133
listxattr("scratch", "ceph.dir.entries\0ceph.dir.files\0ceph.dir.subdirs\0ceph.dir.rentries\0ceph.dir.rfiles\0ceph.dir.rsubdirs\0ceph.dir.rbytes\0ceph.dir.rctime\0", 256) = 133
It might be good to have it stop doing this as well.
--
Jeff Layton <jlayton@xxxxxxxxxx>
