new statx() like interface for libcephfs

new statx() like interface for libcephfs

[Jeff Layton]

I have a patchset queued up for ceph that adds btime (birthtime)
support to it. What was lacking though was a mechanism to get the btime
out of the inode.

Rather than cook up a brand new interface just for the btime, I decided
to "borrow" the work that David Howells did with the new proposed
statx() interface. The pull request to add this to ceph is up here:

     https://github.com/ceph/ceph/pull/9965

Sage has already closed it out which I take to mean that he has pulled
the patches into a staging branch for eventual merge.

It occurs to me though that I didn't ask anyone who is working on the
samba vfs or ganesha fsal code whether they think this interface is
acceptable.

Since Samba and Ganesha are the targeted users of this interface, it'd
be good to have developers from both communities take a look and see if
there are any problems here.

Does anyone see any issues with the above pull request?
-- 
Jeff Layton <jlayton@redhat.com>

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new statx() like interface for libcephfs

[Daniel Gryniewicz]

Is stx_version a generation ID for the inode that can be used for the
NFSv4 Change ID?  If so, that would be quite useful to us.  Otherwise,
I'm not sure there's that much in there that's useful beyond what stat
already provides, unless I'm missing something.

On Tue, Jun 28, 2016 at 2:17 PM, Jeff Layton <jlayton@redhat.com> wrote:
> I have a patchset queued up for ceph that adds btime (birthtime)
> support to it. What was lacking though was a mechanism to get the btime
> out of the inode.
>
> Rather than cook up a brand new interface just for the btime, I decided
> to "borrow" the work that David Howells did with the new proposed
> statx() interface. The pull request to add this to ceph is up here:
>
>      https://github.com/ceph/ceph/pull/9965
>
> Sage has already closed it out which I take to mean that he has pulled
> the patches into a staging branch for eventual merge.
>
> It occurs to me though that I didn't ask anyone who is working on the
> samba vfs or ganesha fsal code whether they think this interface is
> acceptable.
>
> Since Samba and Ganesha are the targeted users of this interface, it'd
> be good to have developers from both communities take a look and see if
> there are any problems here.
>
> Does anyone see any issues with the above pull request?
> --
> Jeff Layton <jlayton@redhat.com>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new statx() like interface for libcephfs

[Jeff Layton]

On Tue, 2016-06-28 at 14:53 -0400, Daniel Gryniewicz wrote:
> Is stx_version a generation ID for the inode that can be used for the
> NFSv4 Change ID?  If so, that would be quite useful to us.  Otherwise,
> I'm not sure there's that much in there that's useful beyond what stat
> already provides, unless I'm missing something.
> 

Yeah, I think that's the idea behind that field in statx calls, but
I'll note that I didn't wire that up here. That is the nice thing about
the proposed statx API though. We can add stuff like that in a
piecemeal fashion, as long as the callers check the stx_mask to make
sure the returned values are legit.

I'll look at whether it's possible to wire that up as well if it's
helpful for ganesha.

> On Tue, Jun 28, 2016 at 2:17 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > 
> > I have a patchset queued up for ceph that adds btime (birthtime)
> > support to it. What was lacking though was a mechanism to get the btime
> > out of the inode.
> > 
> > Rather than cook up a brand new interface just for the btime, I decided
> > to "borrow" the work that David Howells did with the new proposed
> > statx() interface. The pull request to add this to ceph is up here:
> > 
> >      https://github.com/ceph/ceph/pull/9965
> > 
> > Sage has already closed it out which I take to mean that he has pulled
> > the patches into a staging branch for eventual merge.
> > 
> > It occurs to me though that I didn't ask anyone who is working on the
> > samba vfs or ganesha fsal code whether they think this interface is
> > acceptable.
> > 
> > Since Samba and Ganesha are the targeted users of this interface, it'd
> > be good to have developers from both communities take a look and see if
> > there are any problems here.
> > 
> > Does anyone see any issues with the above pull request?
> > --
> > Jeff Layton <jlayton@redhat.com>
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Jeff Layton <jlayton@redhat.com>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new statx() like interface for libcephfs

[Frank Filz]

> Is stx_version a generation ID for the inode that can be used for the
> NFSv4 Change ID?  If so, that would be quite useful to us.  Otherwise, I'm
not
> sure there's that much in there that's useful beyond what stat already
> provides, unless I'm missing something.

Even if stx_version isn't available for a change attribute, btime converts
to NFS v4 create time.

Frank

> On Tue, Jun 28, 2016 at 2:17 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > I have a patchset queued up for ceph that adds btime (birthtime)
> > support to it. What was lacking though was a mechanism to get the
> > btime out of the inode.
> >
> > Rather than cook up a brand new interface just for the btime, I
> > decided to "borrow" the work that David Howells did with the new
> > proposed
> > statx() interface. The pull request to add this to ceph is up here:
> >
> >      https://github.com/ceph/ceph/pull/9965
> >
> > Sage has already closed it out which I take to mean that he has pulled
> > the patches into a staging branch for eventual merge.
> >
> > It occurs to me though that I didn't ask anyone who is working on the
> > samba vfs or ganesha fsal code whether they think this interface is
> > acceptable.
> >
> > Since Samba and Ganesha are the targeted users of this interface, it'd
> > be good to have developers from both communities take a look and see
> > if there are any problems here.
> >
> > Does anyone see any issues with the above pull request?
> > --
> > Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More
> majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
>
----------------------------------------------------------------------------
--
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape