15

When we call close(<fd>), does it automatically do fsync() to sync to the physical media?

tshepang
  • 12,111
  • 21
  • 91
  • 136
user1783732
  • 1,599
  • 5
  • 22
  • 44

3 Answers3

17

It does not. Calling close() DOES NOT guarantee that contents are on the disk as the OS may have deferred the writes.

As a side note, always check the return value of close(). It will let you know of any deferred errors up to that point. And if you want to ensure that the contents are on the disk always call fsync() and check its return value as well.

One thing to keep in mind is what the backing store is. There are devices that may do internal write deferring and content can be lost in some cases (although newer storage media devices typically have super capacitors to prevent this, or ways to disable this feature).

tshepang
  • 12,111
  • 21
  • 91
  • 136
Jesus Ramos
  • 22,940
  • 10
  • 58
  • 88
  • Calling `fsync()` *doesn't either*, for the same reasons (the hardware might have deferred the writes). – Frédéric Hamidi Mar 11 '13 at 20:57
  • @FrédéricHamidi `fsync()` forces the writes to storage, under what conditions would fsync not guarantee contents on the disk (except odd failures and hardware deferred writes which can't be controlled in some cases)? – Jesus Ramos Mar 11 '13 at 20:59
  • There might be (and usually is) another layer of cache in the disk controller, so even `fsync()` cannot guarantee your data has made it to the the actual hardware. The [man page](http://linux.die.net/man/2/close) for `close()` does mention this. – Frédéric Hamidi Mar 11 '13 at 21:01
  • 2
    @FrédéricHamidi: `fsync`, by definition, commits data to stable storage. If it does not, then your system is not POSIX-compliant (i.e., buggy). Yes there are many buggy systems in the world, and yes many of them run Linux, but that does not invalidate this answer, which is perfectly correct. – Nemo Mar 11 '13 at 21:01
  • @Nemo Agreed. There are some hardware things that cannot be controlled and newer hardware that does defer writes has ways to make sure that even under failure that the data is persisted (power/system failure at least). – Jesus Ramos Mar 11 '13 at 21:02
  • 1
    @Nemo, my first comment originated at a time when this answer only consisted in its first paragraph. Things have changed since then, but I agree it is valid, and never said otherwise. – Frédéric Hamidi Mar 11 '13 at 21:03
  • @FrédéricHamidi Yes, that is why I decided to update it to include details about certain hardware that does not guarantee it. – Jesus Ramos Mar 11 '13 at 21:08
2

No.

From man 2 close

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)

John Carter
  • 53,924
  • 26
  • 111
  • 144
1

From man 2 close:

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hard-ware at this point.)

To answer your question, NO, close() does not guarantee fsync()

close only closes the file descriptor for the process and removes any record locks associated with the process.

Tuxdude
  • 47,485
  • 15
  • 109
  • 110