On Tue, 21 Dec 1999 22:17:20 +1100 (EST), Neil Brown
<neilb@cse.unsw.edu.au> said:
>> Let me explain: The problem is that NFS relies on the user sending the
>> RPC authentication each and every time we access data on the
>> server. ...
> Suppose I open a file and write bytes 0-127. Then you open the file
> and write bytes 128-511. Both of these go to the server as UNSTABLE
> writes, presumably with my and your credentials respectively.
> But suppose the server restarts before we do a commit - the data has
> to be written again.
Right, but isn't this basically the same problem that we already have in
NFSv2? Last time we looked, when we had shared writes on a page on
NFSv2 we'd just resort to doing uncached writethrough. Effectively we
are using the writing thread's process context as the cache for the
credentials.
Appying the same rule to NFSv3 just requires that we commit the writes
too in the calling thread when we get shared page writes. Once we get
into that scenario, correctness is far more important than performance.
> Thinking more about keeping UNSTABLE writes in the client cache, it
> occurs to me that there would need to be some way for memory pressure
> to encourage the client to commit cached writes so that memory can be
> freed up, much like Stephen Tweedie wants for his journalling
> filesystem? Is there really a similarity here or am I imagining it?
Absolutely: right now the VM only really understands memory pressure on
dirty data if the data is in the buffer cache. The suggested
per-address_space memory pressure callbacks would certainly allow NFS to
start doing early commits of dirty data if the cache memory was needed
for something else.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/