Recent Features
| |||||||||||||
Ramdisks and hard drives as cache devicesRamdisks and hard drives as cache devicesPosted Jul 8, 2010 23:26 UTC (Thu) by jlayton (subscriber, #31672)In reply to: Ramdisks and hard drives as cache devices by butlerm Parent article: Bcache: Caching beyond just RAM
> NFS servers are supposed to do synchronous writes, right? (Reliable, crash resistant) write behind caching would be outstanding.
Not since NFSv3 was implemented. That gave the ability to do safe asynchronous writes. The client sends a bunch of WRITEs to the server and then issues a COMMIT. If the server crashes, the client will reissue uncommitted writes.
With NFSv2 however, you're correct that the server is supposed to do sync writes (and most do these days, at least by default).
(Log in to post comments)
Ramdisks and hard drives as cache devices Posted Jul 20, 2010 11:38 UTC (Tue) by neilbrown (subscriber, #359) [Link]
Yes, NFSv3 helps with writing large files. But metadata operations (create, unlink, chmod, mv) still need to be synchronous and some workloads can be very metadata-heavy (untar is a good example, 'make' on a big project tends to delete and create lots of relatively small files too).
So a low-latency cache can definitely improve the performance of an NFS server.
Ramdisks and hard drives as cache devices Posted Jul 22, 2010 20:59 UTC (Thu) by nix (subscriber, #2304) [Link]
Unfortunately if you want to spot cache invalidations, the lack of leases on NFSv3 is a killer, because you still have to roundtrip to the server to see if your cache is stale, and roundtrips are the slow part :( fs-cache slows NFS *down* quite considerably in my experience, for exactly this reason.
|
|||||||||||||