Does close() call fsync() on Linux? [duplicate]
Asked Answered
B

3

15

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

Brackish answered 11/3, 2013 at 20:55 Comment(0)
C
18

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).

Coronal answered 11/3, 2013 at 20:57 Comment(7)
Calling fsync() doesn't either, for the same reasons (the hardware might have deferred the writes).Aha
@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)?Coronal
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 for close() does mention this.Aha
@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.Danuloff
@Danuloff 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).Coronal
@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.Aha
@FrédéricHamidi Yes, that is why I decided to update it to include details about certain hardware that does not guarantee it.Coronal
S
3

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.)

Sorrento answered 11/3, 2013 at 20:59 Comment(0)
P
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.

Projection answered 11/3, 2013 at 21:0 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.