3 ms·

Not a block device, so not having cgroups (read/write bps limiting + iops limiting) is one annoyance of NFS in large deployments

• Karunamon 10y ago
  I'd also add extreme fault intolerance. Even when you're mounting soft, or hard+intr, NFS failures have a way of requiring reboots to fully fix.
  • Scaevolus 10y ago
    The intr mount option has been a no-op for 8 years. /bin/umount does an fstat before the umount syscall, so if an NFS mount is broken, it will probably hang forever instead of unmounting it! You can invoke the syscall directly to get the behavior you need.
    • acdha 10y ago
      That hasn't been dependable in my experience - the best workaround I've found is either a lazy unmount + remount if you can tolerate the hung process taking the full NFS retry timeout to unblock or downing the network interface to accelerate the process.
  • xir78 10y ago
    This is fair to a degree, but vendors have VIPs that make failures fairly transparent. But if you need low latency on a large data set is there something better? Where low latency means <100ma reads
• X86BSD 10y ago
  So use Jails, ZFS and rctl. Problem solved.
  • jamespo 10y ago
    How does that fix a client accessing network storage?
    • X86BSD 10y ago
      You can use Samba with it. Unless you absolutely require NFS, samba is far more robust and less prone to needing to be hard rebooted.