svn commit: r222466 - head/sbin/umount

[Rick Macklem]

> 
> 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