> This effect is often particularly pronounced with NFS, where calls might block for hours or even indefinitely if the underlying network filesystem goes away.

I can't tell you how many times I've had to debug a stuck process and it turns out that the logs indicated the NFS had a hiccup a day or two ago during a file read or write and the process was never notified of a file error. It's f!@#ing frustrating. Worse, though, was CIFS.

I routinely have to run file system scans on a giant NFS filer, and even without a hiccup, out of a 100M stat or read calls, ten or so will just never finish. In Go, I have to wrap the call with a channel thing and a time out and hope I don’t run out of threads before scanning all 400 M files.

Just in case anyone isn't aware there is a mount flag called "soft" that allows the NFS client (and some other network filesystems) to timeout or be interrupted, i.e. the process won't get stuck in 'D' (device wait) state.

That is the other extreme, and is also wrong. write(2) does not block until the write to disk is completed, that's what we have fsync(2).

No, that is incorrect. I think you're confused as to what "blocking syscall" means.

A blocking syscall doesn't always block, but it can always block because its interface is designed to block. Write(2) to a disk file can always block, 100% of the time. It is always considered a blocking syscall, even when it happens to not take very long due to cache optimizations.

Every single blocking syscall can sometimes return right away. This has no bearing on whether it is, or isn't, a potentially blocking call.

GGP was objecting to the fact that write always return immediately (writing to memory buffer, no back pressure), and GP said:

> Write calls to regular files will block until they are complete

I therefore understood "complete" to be the opposite to "only into buffers" in that context, e.g. all the way to disk. That is what I'm objecting to.

As to write(2) being a "blocking syscall" in the technical sense, I don't think I agree either. Of course it has that potential, but a write(2) to a regular file does not block in the sense of an interruptible block, or in the sense that O_NONBLOCK or select() can be used to avoid it. It is a "disk sleep" that is generally very different.

Blocking calls often (perhaps usually) don't block. This has nothing to do with the definition.

> As to write(2) being a "blocking syscall" in the technical sense, I don't think I agree either.

Well, you are wrong.

> Of course it has that potential, but a write(2) to a regular file does not block in the sense of an interruptible block, or in the sense that O_NONBLOCK or select() can be used to avoid it.

These have nothing whatsoever to do with whether a syscall is blocking or not. You can't use them on wait(2) either, can you?

Please stop arguing about things you clearly know nothing about.

> Please stop arguing about things you clearly know nothing about.

You could have shown your true color outright and saved me the time. You don't care what I mean, you don't care what anybody means, you will just argue semantics to find a possible meaning where you're right. Well congrats.

I don't care what you mean because it's clear you don't know what you're talking about.

Someone in your position should be posting questions, not arguments.

Sure, I will stop argumenting because you told me to. Thanks for the advice given while "you didn't care what I meant", it's as invaluable as you think.