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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).