> > If it masks, for example, lateny for a synchronous RPC to the remote > mountd to > deregister the mountpoint, allowing a cache flush and unmount to take > place > concurrently, that might be a useful benefit. I'm not sure I see any > evidence > that is the case in the source code, however. > Well, I suppose write latency will often be higher for NFS than other mount points. The case where I think the sync(2) might help from a performance point of view might be (I'm talking through my hat here. Haven't benchmarked or looked at it closely and don't intend to:-): - does a "umount -a" when there are a lot of /etc/fstab entries with a lot of dirty blocks to be written out. --> the writes would be started for all file systems and then they would be unmount(2)'d one at a time. It might be quite a while before the last fs gets an unmount(2), so the blocks "might" have been written out by then.
on the other hand, take the above example and replace "umount -a" with "umount /x" where "/x" is a single fs with no dirty blocks and... --> for this one, the sync(2) would just slow it down, by going through all the other fs's... rick _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"