From: Erik Walthinsen <omega@pdxcolo.net>
To: Greg Banks <gnb@sgi.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: Converting open filehandles to pathnames
Date: Sat, 08 May 2004 17:43:50 -0700 [thread overview]
Message-ID: <1084063428.714.40.camel@omikron> (raw)
In-Reply-To: <20040509072418.GB18762@sgi.com>
On Sun, 2004-05-09 at 00:24, Greg Banks wrote:
> Generally the device and inode of the file are encoded in the
> file handle itself rather than mapped in the server; this is
> the easiest way of satisfying the requirement that the filehandles
> be stable across server reboots.
Oh. Duh. I was assuming the filehandles were randomly assigned by the
server, didn't think about the requirements filehandle continuity would
impose... I suppose it's just plain cheaper too.
> If your NFS server is a Linux box, see the comments in
> include/linux/nfsd/nfsfh.h for a description of the format
> of Linux' file handles.
Heh, found the inode in the filehandle in ethereal just by inspection,
will have to hack my script tomorrow to make use of it.
> Also, ethereal will pick apart and display Linux file handles
> (unless the underlying server fs is XFS).
The version I have (debian/sid ethereal-0.10.3) doesn't display
filehandles as anything but length and data, though I have used the mode
that does what my script was trying to do, which will try to find and
cache the translation. However, that only works when the getattrs are
present <g> Not sure if running ethereal on the NFS server itself would
help, but it's got no head and no X anyway.
Well, I think my problem is solved, thanks for the help! ;-)
Now if someone just had as good an answer to the "what is a client?"
question.... You might imagine my interest in that is more than
academic, with 100's of *long*-duration filehandles in the GB+ range
each, yet over only a few physical client machines.
Thanks,
Omega
aka Erik Walthinsen
omega@pdxcolo.net
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-05-09 8:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-08 23:33 Converting open filehandles to pathnames Erik Walthinsen
2004-05-09 7:24 ` Greg Banks
2004-05-09 0:43 ` Erik Walthinsen [this message]
2004-05-10 0:26 ` seth vidal
2004-05-10 3:00 ` Garrick Staples
2004-05-09 21:11 ` Erik Walthinsen
2004-05-10 8:02 ` Bogdan Costescu
2004-05-10 14:20 ` Erik Walthinsen
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=1084063428.714.40.camel@omikron \
--to=omega@pdxcolo.net \
--cc=gnb@sgi.com \
--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 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.