From: Greg Banks <gnb@melbourne.sgi.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Linux NFS Mailing List <nfs@lists.sourceforge.net>
Subject: Re: [PATCH] SGI 907674: document fsid export option
Date: Tue, 24 Feb 2004 15:31:06 +1100 [thread overview]
Message-ID: <403AD38A.58FACE61@melbourne.sgi.com> (raw)
In-Reply-To: 16442.52922.613916.868991@notabene.cse.unsw.edu.au
Neil Brown wrote:
>
> On Tuesday February 24, gnb@melbourne.sgi.com wrote:
> >
> > Aha, it's embarrassment time. Since sending the patch I've discovered
> > that this part
> >
> > > > +instead of a number derived from the major and minor number of the
> > > > +block device on which the filesystem is mounted. Any 32 bit number
> > > > +can be used, but it must be unique amongst all the exported filesystems.
> >
> > is wrong; the fsid passes through a dev_t interface and is silently
> > truncated to 16 bits. The following fixes my gaffe. Sorry.
> >
>
> Hmm... I'd much rather we actually used 32 bits.
Actually the field in the file handle on the wire is 64 bits:
/* fs/nfsd/nfs3xdr.c */
static inline u32 *
encode_fattr3(struct svc_rqst *rqstp, u32 *p, struct svc_fh *fhp)
{
[...]
if (rqstp->rq_reffh->fh_version == 1
&& rqstp->rq_reffh->fh_fsid_type == 1
&& (fhp->fh_export->ex_flags & NFSEXP_FSID))
p = xdr_encode_hyper(p, (u64) fhp->fh_export->ex_fsid);
else
p = xdr_encode_hyper(p, (u64) inode->i_dev);
[...]
}
> Where does the
> truncate happen? nfs-utils / kernel-2.4 / kernel-2.6 ??
The fsid is passed through the ex_dev field in struct nfsctl_export,
which (presumably for compatibility) is 16 bits both in 2.4 and 2.6.
There are two copies, one each in the kernel and nfs-utils.
/* linux/include/linux/nfsd/syscall.h */
/* EXPORT/UNEXPORT */
struct nfsctl_export {
char ex_client[NFSCLNT_IDMAX+1];
char ex_path[NFS_MAXPATHLEN+1];
__kernel_dev_t ex_dev; <---
__nfsd_ino_t ex_ino;
int ex_flags;
__kernel_uid_t ex_anon_uid;
__kernel_gid_t ex_anon_gid;
};
/* nfs-utils/support/include/nfs/nfs.h */
/* EXPORT/UNEXPORT */
struct nfsctl_export {
char ex_client[NFSCLNT_IDMAX+1];
char ex_path[NFS_MAXPATHLEN+1];
__nfsd_dev_t ex_dev; <---
__kernel_ino_t ex_ino;
int ex_flags;
__kernel_uid_t ex_anon_uid;
__kernel_gid_t ex_anon_gid;
};
I agree the truncate is unfortunate. We have a 2.4.25 machine here with
dozens of exports each with an fsid= option automatically created by taking
the first 2 bytes of the md5sum of their names (because their devices aren't
stable) and some of the fsids are uncomfortably close.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-02-24 4:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-29 3:48 [PATCH] SGI 907674: document fsid export option Greg Banks
2004-01-29 23:45 ` Greg Banks
2004-02-24 3:39 ` Neil Brown
2004-02-24 4:07 ` Greg Banks
2004-02-24 4:10 ` Neil Brown
2004-02-24 4:31 ` Greg Banks [this message]
2004-02-25 0:04 ` Neil Brown
2004-02-25 0:31 ` Greg Banks
2004-02-25 3:21 ` Neil Brown
2004-02-25 4:39 ` Greg Banks
2004-02-27 11:37 ` Greg Banks
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=403AD38A.58FACE61@melbourne.sgi.com \
--to=gnb@melbourne.sgi.com \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
/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