BTW - everyone here keeps assuming that close(2) is called on disk files, what about other types of file descriptors (sockets, pipes, character and block devices, "virtual filesystem" files)? How would you adjust your answers for that case?
On 28 July 2012 16:56, Shachar Shemesh <shac...@shemesh.biz> wrote: > On 07/27/2012 02:52 PM, Elazar Leibovich wrote: > > > (as mentioned earlier, the "no space left" could just as well happen after > the file was closed, so I don't mind that much it's not reported on a > close()) > > Ehm, no. > > First of all, please note a subtle but important difference between your > question and Orna's answer. You asked about close, she answered about > fclose. > > Fclose is an stdio function, and performs a flush of the (user space) > buffers. As such, it is possible for it to run out of disk space. Close, on > the other hand, might only run out of disk space on remote file systems > (such as nfs), and even then, it depends on the local cache coherency > policy. I fail to see how an "out of disk space" might possibly happen > AFTER close, as all that's left then are caches. > > Please note that just because the data is in the OS caches, rather than on > disk, this does not mean that anything can change as far as file system > notion of the data goes. By the time close returns, the OS has already > allocated space for the data, and decided where on the disk this data > should go. It is not possible for it to fail after that point because of > lack of disk space. > > As I said before, for local file systems, this is also true of "write". > The main reason we need to check the return code of "close" is because you > never know who will run your program over NFS. Over NFS, for performance > reasons, it is possible for a "write" command to fail after the kernel has > already returned to user space with a success indication. Doing it > otherwise will result in horrible latency for anyone working over NFS. All > such errors will get reported on the next operation over the file > descriptor: close. > > Shachar > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd.http://www.lingnu.com > > > _______________________________________________ > Linux-il mailing list > Linux-il@cs.huji.ac.il > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il > > -- [image: View my profile on LinkedIn] <http://www.linkedin.com/in/gliderflyer>
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
