man nfs

Posted Mar 5, 2020 18:30 UTC (Thu) by flussence (guest, #85566)
In reply to: man nfs by mchouque
Parent article: Quote of the week

Mine seems aware of it:
> intr / nointr This option is provided for backward compatibility. It is ignored after kernel 2.6.25.
> […]
> 9 October 2012 NFS(5)
(It ought to suggest a suitable replacement there: having the default failure state lock up entire terminal windows so hard they don't respond to sigterm/quit is kind of rude…)

But NFS in particular really does suffer from cargo-culting and a lack of a single obvious, authoritative, current set of documentation - I don't know how official linux-nfs.org is supposed to be, but some of the links there were either last updated before NFSv4.0 existed or proclaim it to be new and experimental. When I was trying to get it to work I had to resort to the ancient ritual of posting something wrong on the internet to get lectured with corrections.

man nfs

Posted Mar 5, 2020 22:07 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

IMHO this is a problem with the entire space of filesystems that purport to comply with POSIX. NFS is particularly bad because it has a long history of failing to adequately comply with POSIX, but in general, the POSIX filesystem API seems to be a "worst of all possible worlds" situation:

Filesystem developers heavily optimize the "no fsyncs ever" case, because POSIX offers no guarantees in that case. When people ask for a richer API, their usual reaction is somewhere between "just call fsync" and "why would you want that?"
Database developers call fsync religiously, because POSIX offers no guarantees if you don't. Then they complain about performance and resort to nasty hacks like O_DIRECT, which tends to annoy the FS developers.
(Some) application developers blithely ignore all of this and just assume their data will be fine. They don't call fsync or necessarily even know that it exists. They might stuff their data into an SQLite database (or a "real" database) which does it for them. The prudent ones also do periodic autosaving, and recover the last usable save if the latest data on disk is bad. Occasionally, the filesystem developers will manage to break someone's autosaving system (which was never guaranteed to work in the first place), and then Bad Things happen and people yell at each other.
End users are usually in a position of even greater ignorance than the application developers. Inevitably, some of their data will get lost, since it's completely impossible to avoid losing any data whatsoever without slowing performance to a crawl. No matter what data gets lost, some users will be unhappy.

This process inevitably leads to O_PONIES conflicts and people talking past each other about what they actually want. It is unpleasant to watch from my vantage point on the sidelines; I can't imagine how immensely frustrating it must be to actually participate in these Sisyphean discussions.

man nfs

Posted Mar 6, 2020 19:23 UTC (Fri) by flussence (guest, #85566) [Link]

When you put it that way, I can see why everything's slowly getting replaced with HTTP…

man nfs

Posted Mar 6, 2020 4:00 UTC (Fri) by willy (subscriber, #9762) [Link] (5 responses)

> (It ought to suggest a suitable replacement there: having the default failure state lock up entire terminal windows so hard they don't respond to sigterm/quit is kind of rude…)

Hmm? The way it works is that any fatal signal will cause the task to die. There's not really anything else we can do, thanks to programmers never checking whether they got a short read/write.

What we're still bad at with NFS is that a write or an fsync will cause an uninterruptible sleep (at least last time I looked). I haven't had the tuits to fix that.

man nfs

Posted Mar 6, 2020 19:45 UTC (Fri) by flussence (guest, #85566) [Link] (4 responses)

I've had columns of "D" appear in top for reasons I've never really figured out. Some of it's autofs struggling to mount it, but sometimes it freezes up on already-mounted filesystems. I've had hung mounts that I'm pretty certain were caused by jumbo ethernet frames too - any mtu above about 4000 seems flaky.

To be clear and just so I'm not constantly complaining: the other 99% of the time it works it's fantastic. I'm grateful for all the work that went into this. Even if these few sore spots don't get fixed, I feel less frustrated just having the acknowledgement that it's like that sometimes and I'm not imagining it.

man nfs

Posted Mar 6, 2020 19:54 UTC (Fri) by willy (subscriber, #9762) [Link]

Next time you have a task stuck in D state, it'd be great if you could send /proc/$pid/stack to linux-fsdevel, because I strongly feel that when a user hits ^C, the task should die.

I didn't remove any places which would have been interruptible before, so the only difference is that now non-fatal signals won't interrupt a read.

man nfs

Posted Mar 16, 2020 22:29 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

I've had hung mounts that I'm pretty certain were caused by jumbo ethernet frames too - any mtu above about 4000 seems flaky.

It must be more than that: I've never had hung mounts on the link to the NFS server here, which has an MTU of 6128 (because of limits on one of the network cards in question), not on NFSv3 nor NFSv4.0 nor NFSv4.1. And if I had hung mounts, I'd know it: my $HOME is on NFS...

man nfs

Posted Mar 19, 2020 8:33 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

Personally, I'm inclined to blame these el cheapo onboard Realtek NICs I keep winding up with… if this was a kernelspace bug I'd hardly be the first to discover it.

man nfs

Posted Mar 19, 2020 22:09 UTC (Thu) by nix (subscriber, #2304) [Link]

It's not even all of those: the machine I'm typing this on has NFSv4 $HOME and a Realtek 8168 and has been more or less flawless. (Not that I'll be using that for much longer: I'm going 10GbE, with an X540-T1, instead. Yes, 10GbE to the desktop is now practical without needing to win the lottery first :) )