All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.