zlacker

[return to "NFS: The Early Years"]
1. smarks+od[view] [source] 2022-06-21 00:35:07
>>chmayn+(OP)
Of course, the first commenter "willy" repeats the canard that statelessness makes no sense:

> The very notion of a stateless filesystem is ridiculous. Filesystems exist to store state.

It's the protocol that's stateless, not the filesystem. I thought the article made a reasonable attempt to explain that.

Overall the article is reasonable but it omits one of the big issues with NFSv2, which is synchronous writes. Those Sun NFS implementations were based on Sun's RPC system; the server was required not to reply until the write had been committed to stable storage. There was a mount option to disable this, but if you enabled it, it exposed you to data corruption. Certain vendors (SGI, if I recall correctly) at some point claimed their NFS was faster than Sun's, but it implemented asynchronous writes. This resulted in the expected arguments over protocol compliance and reliability vs. performance.

This phenomenon led to various hardware "NFS accelerator" solutions that put an NVRAM write cache in front of the disk in order to speed up synchronous writes. I believe Legato and the still-existing NetApp were based on such technology. Eventually the synchronous writes issue was resolved, possibly by NFSv3, though the details escape me.

◧◩
2. kovers+IT1[view] [source] 2022-06-21 14:58:01
>>smarks+od
That's Matthew Wilcox you're referring to, and he's right.

It's not just about reads and writes - doing a stateless protocol for a block device is fine. Think more about unlink...

[go to top]