1

When I issue write(), my data goes to some kernel space buffers. The actual commit to physical layer ("phy-commit") is (likely) deferred, until.. (exactly until what events?)

When I issue a close() for a file descriptor, then

If [...], the resources associated with the open file description are freed

Does it mean releasing (freeing) those kernel buffers which contained my data? What will happen to my precious data, contained in those buffers? Will be lost?

How to prevent that loss?

Via fsync()? It requests an explicite phy-commit. I suppose that either immediately (synchronous call) or deferred only "for short time" and queued to precede subsequent operations, at least destructive ones.

But I do not quite want immediate or urgent phy-commit. Only (retaining my data and) not to forget doing phy-commit later in some time.


From man fclose:

The fclose() function [...] closes the underlying file descriptor.
...
fclose() flushes only the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).

It may suggest that fsync does not have to precede close (or fclose, which contains a close), but can (even have to) come after it. So the close() cannot be very destructive...

  • close, and fclose are sufficient for the data to get to the disk unless there is something like a physical disconnect or power outage in the next few milliseconds. – Grady Player Nov 21 '16 at 16:48
  • 2
    The kernel doesn't free its buffers until it has actually committed the data. You don't need to do anything. – Barmar Nov 21 '16 at 16:48

1 Answers1

1

Does it mean releasing (freeing) those kernel buffers which contained my data? What will happen to my precious data, contained in those buffers? Will be lost?

No. The kernel buffers will not freed before it writes the data to the underlying file. So, there won't be any data loss (unless something goes really wrong - such as power outage to the system). Whether the that data will be immediately written to the physical file is another question. It may dependent on the filesystem (which may be buffering) and/or any hardware caching as well. As far as your user program is concerned, a successful close() call can be considered as successful write to the file.

It may suggest that fsync does not have to precede close (or fclose, which contains a close), but can (even have to) come after it. So the close() cannot be very destructive...

After a call to close(), the state of the file descriptor is left unspecified by POSIX (regardless of whether close() succeeded). So, you are not allowed to use fsync(fd); after the calling close(). See: POSIX/UNIX: How to reliably close a file descriptor.

And no, it doesn't suggest close() can be destructive. It suggests that the C library may be doing its own buffering in the user and suggests to use fsync() to flush it to the kernel (and now, we are in the same position as said before).

Community
  • 1
  • 1
P.P
  • 117,907
  • 20
  • 175
  • 238
  • For the last paragraph in the answer: you can solve it with fileno() and an explicit fflush(): sequence would be fd=fileno(FH); fflush(FH); fsync(fd); fclose(FH); – A.B Nov 21 '16 at 23:58