On Thu, Feb 08, 2018 at 08:21:44PM +0000, Terry Barnaby wrote: > Doesn't fsync() and perhaps sync() work across NFS then when the server has > an async export, No. On a local filesystem, a file create followed by a sync will ensure the file create reaches disk. Normally on NFS, the same is true--for the trivial reason that the file create already ensured this. If your server is Linux knfsd exporting the filesystem with async, the file create may still not be on disk after the sync. > I don't think a program on a remote system is particularly worse off > if the NFS server dies, it may have to die if it can't do any special > recovery. Well-written applications should be able to deal with recovering after a crash, *if* the filesystem respects fsync() and friends. If the filesystem ignores them and loses data silently, the application is left in a rather more difficult position! > > > Only difference from the normal FS conventions I am suggesting is to > > > allow the server to stipulate "sync" on its mount that forces sync > > > mode for all clients on that FS. > > Anyway, we don't have protocol to tell clients to do that. > As I said NFSv4.3 :) Protocol extensions are certainly possible. > > So if you have reliable servers and power, maybe you're comfortable with > > the risk. There's a reason that's not the default, though. > Well, it is the default for local FS mounts so I really don't see why it > should be different for network mounts. It's definitely not the default for local mounts to ignore sync(). So, you understand why I say that the "async" export option is very different from the mount option with the same name. (Yes, the name was a mistake.) And you can see why a filesystem engineer would get nervous about recommending that configuration. > But anyway for my usage NFS sync is completely unusable (as would > local sync mounts) so it has to be async NFS or local disks (13 secs > local disk -> 3mins NFS async-> 2 hours NFS sync). I would have > thought that would go for the majority of NFS usage. No issue to me > though as long as async can be configured and works well :) So, instead what I personally use is a hardware configuration that allow me to get similar performance while still using the default export options. > > Sure. The protocol issues are probably more complicated than they first > > appear, though! > Yes, they probably are, most things are below the surface, but I still think > there are likely to be a lot of improvements that could be made that would > make using NFS async more tenable to the user. > If necessary local file caching (to local disk) with delayed NFS writes. I > do use fscache for the NFS - OpenVPN - FTTP mounts, but the NFS caching time > tests probably hit the performance of this for reads and I presume writes > would be write through rather than delayed write. Haven't actually looked at > the performance of this and I know there are other network file systems that > may be more suited in that case. fscache doesn't remove the need for synchronous file creates. So, in the existing protocol write delegations are probably what would help most; which is why they're near the top of my todo list. But write delegations just cover file data and attributes. If we want a client to be able to, for example, respond to creat() with success, we want write delegations on *directories*. That's rather more complicated, and we currently don't even have protocol proposed for that. It's been proposed in the past and I hope there may be sufficient time and motivation to make it happen some day.... --b. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
