On Mon, Jan 29, 2018 at 08:37:50PM +0000, Terry Barnaby wrote: > Ok, that's a shame unless NFSv4's write performance with small files/dirs > is relatively ok which it isn't on my systems. > Although async was "unsafe" this was not an issue in main standard > scenarios such as an NFS mounted home directory only being used by one > client. > The async option also does not appear to work when using NFSv3. I guess it > was removed from that protocol at some point as well ? This isn't related to the NFS protocol version. I think everybody's confusing the server-side "async" export option with the client-side mount "async" option. They're not really related. The unsafe thing that speeds up file creates is the server-side "async" option. Sounds like you tried to use the client-side mount option instead, which wouldn't do anything. > What is the expected sort of write performance when un-taring, for example, > the linux kernel sources ? Is 2 MBytes/sec on average on a Gigabit link > typical (3 mins to untar 4.14.15) or should it be better ? It's not bandwidth that matters, it's latency. The file create isn't allowed to return until the server has created the file and the change has actually reached disk. So an RPC has to reach the server, which has to wait for disk, and then the client has to get the RPC reply. Usually it's the disk latency that dominates. And also the final close after the new file is written can't return until all the new file data has reached disk. v4.14.15 has 61305 files: $ git ls-tree -r v4.14.15|wc -l 61305 So time to create each file was about 3 minutes/61305 =~ 3ms. So assuming two roundtrips per file, your disk latency is probably about 1.5ms? You can improve the storage latency somehow (e.g. with a battery-backed write cache) or use more parallelism (has anyone ever tried to write a parallel untar?). Or you can cheat and set the async export option, and then the server will no longer wait for disk before replying. The problem is that on server reboot/crash, the client's assumptions about which operations succeeded may turn out to be wrong. --b. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
