Re: /proc through NFS

Thomas Schoebel-Theuer (schoebel@informatik.uni-stuttgart.de)
13 Nov 1996 16:34:47 GMT

In article <96Nov12.100330-0500_est.156320-11040+2250@vger.rutgers.edu>, David Howells <d.howells@nexor.co.uk> writes:
|> I would imagine this is because /proc files in general have zero lengths, and
|> so anything that stat's them will assume that they don't contain anything.
|>
|> I find that less doesn't work on them either.

I'd like to see this corrected, but I see the following problems:

1) Not only the length, but also the mtime should be updated as soon as
the contents changes. This is due to caching on the client. AFAIK the cache
could become inconsistent if this is not obeyed.

2) This could potentially cause infinite retransmissions, if (some) clients
verify the mtime after each read (I don't know whether such clients exist
in networld). Just for reasoning about the semantics of "always-changing"
files...

3) It would be a Great Thing(tm) if named pipes (and possibly devices!) could be
(optionally) read and written over nfs using the same mechanism, at least
in sequential mode. Does anyone know what standards (e.g. POSIX) say about
the semantics of fifos, sockets and devices when mounted over nfs?
Also, there should be some reasoning about security before enabling such
an option...

Just ideas,

-- Thomas