4 ms·

No, as you reasoned out it is absolutely incorrect. Write calls to regular files will block until they are complete, unless some kind of error situation is enco

No, as you reasoned out it is absolutely incorrect. Write calls to regular files will block until they are complete, unless some kind of error situation is encountered. This effect is often particularly pronounced with NFS, where calls might block for hours or even indefinitely if the underlying network filesystem goes away.

inetknght 4y ago
> 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.
- lanstin 4y ago
  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.
tankenmate 4y ago
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.
remram 4y ago
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).
- throwaway09223 4y ago
  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.
  - remram 4y ago
    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.
    - throwaway09223 4y ago
      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.
      - remram 4y ago
        > 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.

inetknght 4y ago

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

lanstin 4y ago
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.

tankenmate 4y ago

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.

remram 4y ago

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

throwaway09223 4y ago
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.
- remram 4y ago
  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.
  - throwaway09223 4y ago
    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.
    - remram 4y ago
      > 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.