From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: torvalds@transmeta.com (Linus Torvalds)
Cc: linux-kernel@vger.kernel.org
Subject: Re: knfsd and FS_REQUIRES_DEV
Date: 12 Dec 2001 03:15:19 +0100 [thread overview]
Message-ID: <shszo4p18w8.fsf@charged.uio.no> (raw)
In-Reply-To: <Pine.LNX.4.33.0112111810160.541-100000@devserv.devel.redhat.com> <20011211.162011.21927662.davem@redhat.com> <9v69ci$5e1$1@penguin.transmeta.com>
In-Reply-To: <9v69ci$5e1$1@penguin.transmeta.com>
>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:
> Well, that actually could work with things like /proc, which
> actually has meaningful inode numbers. They may not be stable
> across reboots, of course, nor even really stable in general,
> but in _theory_ there's nothing to keep us from exporting /proc
> files and potentially other virtual filesystems.
I'd be really interested in seeing an NFS client caching protocol that
could cope with this...
For /proc you don't even *want* stability across reboots. That said,
even if you did, the current VFS API is quite sufficient to allow you
to create a protocol that will satisfy those stability
requirements.
The important thing as far as NFS filehandles are concerned is that
the actual information you put in is invariant over reboots, and that
it suffices to locate a file uniquely. With the current API, that
means that we need at least one unique number to identify the actual
'super_operations->fh_to_dentry()' method to be used. Beyond
that, it is entirely up to the fs how it wants to interpret the rest
of the filehandle...
Cheers,
Trond
prev parent reply other threads:[~2001-12-12 2:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-12 0:13 knfsd and FS_REQUIRES_DEV Elliot Lee
2001-12-12 0:20 ` David S. Miller
2001-12-12 0:45 ` Elliot Lee
2001-12-12 1:21 ` Neil Brown
2001-12-12 0:46 ` Linus Torvalds
2001-12-12 2:15 ` Trond Myklebust [this message]
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=shszo4p18w8.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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