From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Sage Weil <sage@newdream.net>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com,
corbet@lwn.net, neilb@suse.de, npiggin@kernel.dk,
hooanon05@yahoo.co.jp, miklos@szeredi.hu,
linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com,
philippe.deniel@CEA.FR, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V20 02/12] vfs: Add name to file handle conversion support
Date: Thu, 30 Sep 2010 10:56:00 +0530 [thread overview]
Message-ID: <m3k4m3redz.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1009291022350.16498@cobra.newdream.net>
On Wed, 29 Sep 2010 10:26:32 -0700 (PDT), Sage Weil <sage@newdream.net> wrote:
> Hi Aneesh,
>
> On Wed, 29 Sep 2010, Aneesh Kumar K. V wrote:
>
> > On Tue, 28 Sep 2010 16:30:45 -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > By the way, apologies, I can't remember from last time: did you decide
> > > that overflow was really the only case when 255 would be returned from
> > > exportfs_encode_fs()?
> > >
> >
> > All in kernel file system other than cepth return 255 on overflow.
> > ceph return -ENOSPC when there is an EOVERFLOW case. (I also
> > need to fix Ceph to return minimum handle size). I guess ceph usage was
> > correct as per the existing documentation. But the current documentation
> > is wrong and all the file system was returning 255 instead of ENOSPC
> >
> > We look at the returned handle size of exportfs_encode_fh and determine
> > the overflow case in open by handle code. May be i should fix that to
> > include both 255 and ENOSPC ?
> >
> > if ((handle->handle_bytes > f_handle.handle_bytes) ||
> > (retval == 255) || (retval == -ENOSPC)) {
> > /* As per old exportfs_encode_fh documentation
> > * we could return ENOSPC to indicate overflow
> > * But file system returned 255 always. So handle
> > * both the values
> > */
> > /*
> > * set the handle_size to zero so we copy only
> > * non variable part of the file_handle
> > */
> > handle->handle_bytes = 0;
> > retval = -EOVERFLOW;
> > }
> >
> > Attached ceph change below
>
> This looks good to me. If ceph is the only one returning ENOSPC we may as
> well fix it there (and in the documentation) and avoid adding an
> additional return code check. Unless you're worried about out of tree
> file systems?
>
> In any case, I'll add the below patch to the ceph tree.
>
> Thanks!
> sage
>
>
>
>
> >
> > diff --git a/fs/ceph/export.c b/fs/ceph/export.c
> > index 4480cb1..e38423e 100644
> > --- a/fs/ceph/export.c
> > +++ b/fs/ceph/export.c
> > @@ -42,32 +42,37 @@ struct ceph_nfs_confh {
> > static int ceph_encode_fh(struct dentry *dentry, u32 *rawfh, int *max_len,
> > int connectable)
> > {
> > + int type;
> > struct ceph_nfs_fh *fh = (void *)rawfh;
> > struct ceph_nfs_confh *cfh = (void *)rawfh;
> > struct dentry *parent = dentry->d_parent;
> > struct inode *inode = dentry->d_inode;
> > - int type;
> > + int connected_handle_length = sizeof(*cfh)/4;
> > + int handle_length = sizeof(*fh)/4;
> >
> > /* don't re-export snaps */
> > if (ceph_snap(inode) != CEPH_NOSNAP)
> > return -EINVAL;
> >
> > - if (*max_len >= sizeof(*cfh)) {
> > + if (*max_len >= connected_handle_length) {
> > dout("encode_fh %p connectable\n", dentry);
> > cfh->ino = ceph_ino(dentry->d_inode);
> > cfh->parent_ino = ceph_ino(parent->d_inode);
> > cfh->parent_name_hash = parent->d_name.hash;
> > - *max_len = sizeof(*cfh);
> > + *max_len = connected_handle_length;
> > type = 2;
> > - } else if (*max_len > sizeof(*fh)) {
> > - if (connectable)
> > - return -ENOSPC;
> > + } else if (*max_len >= handle_length) {
> > + if (connectable) {
> > + *max_len = connected_handle_length;
> > + return 255;
> > + }
> > dout("encode_fh %p\n", dentry);
> > fh->ino = ceph_ino(dentry->d_inode);
> > - *max_len = sizeof(*fh);
> > + *max_len = handle_length;
> > type = 1;
> > } else {
> > - return -ENOSPC;
> > + *max_len = handle_length;
> > + return 255;
> > }
> > return type;
> > }
> >
Part of the patch that update *max_len on error is added by the
open by handle patch series for other file system. If I split that
part from the patch above it will create merge conflict later. So i am not
sure how to handle that. But if you are ok with everything in a single
patch you can add
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
-aneesh
next prev parent reply other threads:[~2010-09-30 5:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 19:36 [PATCH -V20 00/12] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 01/12] exportfs: Return the minimum required handle size Aneesh Kumar K.V
2010-09-28 19:52 ` J. Bruce Fields
2010-09-29 5:34 ` Aneesh Kumar K. V
2010-09-28 19:36 ` [PATCH -V20 02/12] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-09-28 20:30 ` J. Bruce Fields
2010-09-29 8:16 ` Aneesh Kumar K. V
2010-09-29 17:26 ` Sage Weil
2010-09-30 5:26 ` Aneesh Kumar K. V [this message]
2010-09-28 19:36 ` [PATCH -V20 03/12] vfs: Add open by file handle support Aneesh Kumar K.V
2010-09-29 5:27 ` Aneesh Kumar K. V
2010-09-28 19:36 ` [PATCH -V20 04/12] vfs: Add handle based readlink syscall Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 05/12] vfs: Add handle based stat syscall Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 06/12] vfs: Add handle based link syscall Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 07/12] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 08/12] x86: Add new syscalls for x86_64 Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 09/12] unistd.h: Add new syscalls numbers to asm-generic Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 10/12] vfs: Export file system uuid via /proc/<pid>/mountinfo Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 11/12] ext3: Copy fs UUID to superblock Aneesh Kumar K.V
2010-09-28 19:36 ` [PATCH -V20 12/12] ext4: " Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k4m3redz.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@sun.com \
--cc=bfields@fieldses.org \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=hooanon05@yahoo.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=npiggin@kernel.dk \
--cc=philippe.deniel@CEA.FR \
--cc=sage@newdream.net \
--cc=sfrench@us.ibm.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.