Hacker News Reader

Comment by kotlin2 | Hacker News Reader

The write call returns how many bytes were accepted: https://man7.org/linux/man-pages/man2/write.2.html

> The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes. (See also pipe(7).)

View on HN

That doesn't answer the question. Blocking isn't a matter of how much data is written, but a matter of when the system call completes. Other parts of that man page imply that write(2) may block, unless the fd was opened with O_NONBLOCK (in which case you'll get an EAGAIN error instead of it blocking).

> (in which case you'll get an EAGAIN error instead of it blocking).

You won't. O_NONBLOCK cannot be used with regular files. That part of the manpage is discussing other non-socket file types.

Disk i/o via write(2) is always a blocking call. Always. 100% of the time, no exceptions.

"It's complicated." Generally, with a regular file, write(2) will complete as soon as the the data makes it to filesystem buffers/cache. The data is probably not on disk when the call completes. This depends on how the file was opened (O_FSYNC, O_DIRECT, etc.) and the underlying filesystem itself. There are many other details at work, like actual file system, memory pressure (there may not be enough buffers), cache in the physical disk device or controller, etc. So the write call itself is "blocking", but the physical writes are (generally) not synchronous with the call.

Yes, whether a write blocks is really about whether the application can do anything else while the write is processed; whether the application is told the write is done when it lands in a cache or when it is actually on stable storage is a separate question.

Reply on news.ycombinator.com