Is it safe to write a descriptor after ENOSPC

Imagine this situation:

  • one process (A) writes data continuously to disk, creating large files to which it appends data using separate write () commands
  • another process (B), continuously deletes files from disk
  • it is assumed that (B) is deleting data fast enough for (A) to have room for writing. However, this is not guaranteed.
  • Imagine (A) is trying to write an open handle and receives an ENOSPC. Since (A) knows that (B) has to make some room, (A) would like to repeat the recording.

Question: Is it safe for (A), after receiving ENOSPC, to try to write on the same descriptor that ENOSPC was on? I couldn't find any information on this, and I'm wondering if it might depend on things like OS, filesystem, etc.

+3


source to share


1 answer


There is nothing special about ENOSPC. This indicates that the recording failed, and the reason it failed is doing something to the device that does not have enough free space to complete the operation. It does not leave a file descriptor in bad or undefined state. The file descriptor remains in the same state as before the call. You can safely keep trying as long as you want.



Please note that you must be prepared for a short entry. If the write system call does not have enough space to complete the operation instead of abandoning ENOSPC, it can write as much as it can and returns successfully. In this case, the return value will indicate the actual number of bytes written.

+2


source







All Articles