* Re: fsync() after close() and re-open -- insights appreciated [not found] <74319d6c-d429-9ea1-8f6d-ddb16834a796@nh2.me> @ 2018-05-03 13:28 ` Amir Goldstein 2018-05-03 14:30 ` Niklas Hambüchen 0 siblings, 1 reply; 3+ messages in thread From: Amir Goldstein @ 2018-05-03 13:28 UTC (permalink / raw) To: Niklas Hambüchen; +Cc: Linux FS-devel Mailing List On Thu, May 3, 2018 at 3:30 PM, Niklas Hambüchen <mail@nh2.me> wrote: > Hello, > > here's a simple question > I'm having trouble finding answers to that is > probably trivial to answer for file system developers. > Not trivial :) Are you asking the question without being aware of all the discussions that led to this patch https://lkml.org/lkml/2018/4/23/994 > Does a sequence of close()/re-open()/fsync() provide the same durability > guarantees as fsync()/close()? The short answer is no, the latter provides a better guaranty. The longer answer is that durability guarantees depends on kernel version, because situation has been changing in v4.13, v4.14 and now again in v4.17-rc and stable kernels. > > http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html > specifies that > > "The fsync() function shall request that all data for the open file > descriptor named by fildes is to be transferred to the storage device" > > which seems to restrict the statement to "for the open file descriptor", > possibly suggesting that close()/open()/fsync() may not have the desired > effect. > > Being able to link to an authorative answer would be very appreciated. > Sadly, there is no documentation at the level that you desire. Thanks, Amir. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fsync() after close() and re-open -- insights appreciated 2018-05-03 13:28 ` fsync() after close() and re-open -- insights appreciated Amir Goldstein @ 2018-05-03 14:30 ` Niklas Hambüchen 2018-05-03 19:58 ` Amir Goldstein 0 siblings, 1 reply; 3+ messages in thread From: Niklas Hambüchen @ 2018-05-03 14:30 UTC (permalink / raw) To: Amir Goldstein; +Cc: Linux FS-devel Mailing List Hello Amir, thanks a lot for your reply! > Are you asking the question without being aware of all the discussions > that led to this patch https://lkml.org/lkml/2018/4/23/994 Yes, I was not aware of those. Am I right assuming that what you mention is what Posgres is now referring to as "fsyncgate" (https://wiki.postgresql.org/wiki/Fsync_Errors)? > The short answer is no, the latter provides a better guaranty. > The longer answer is that durability guarantees depends on kernel version, > because situation has been changing in v4.13, v4.14 and now again in > v4.17-rc and stable kernels. Thanks for this summary. >> Being able to link to an authorative answer would be very appreciated. > > Sadly, there is no documentation at the level that you desire. Ah, I was calling the the answer I might get on this list the authoritative answer that I would link to :) Niklas ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fsync() after close() and re-open -- insights appreciated 2018-05-03 14:30 ` Niklas Hambüchen @ 2018-05-03 19:58 ` Amir Goldstein 0 siblings, 0 replies; 3+ messages in thread From: Amir Goldstein @ 2018-05-03 19:58 UTC (permalink / raw) To: Niklas Hambüchen; +Cc: Linux FS-devel Mailing List On Thu, May 3, 2018 at 5:30 PM, Niklas Hambüchen <mail@nh2.me> wrote: > Hello Amir, > > thanks a lot for your reply! > >> Are you asking the question without being aware of all the discussions >> that led to this patch https://lkml.org/lkml/2018/4/23/994 > > Yes, I was not aware of those. > > Am I right assuming that what you mention is what Posgres is now > referring to as "fsyncgate" (https://wiki.postgresql.org/wiki/Fsync_Errors)? > Correct. Thanks, Amir. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-05-03 20:04 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <74319d6c-d429-9ea1-8f6d-ddb16834a796@nh2.me> 2018-05-03 13:28 ` fsync() after close() and re-open -- insights appreciated Amir Goldstein 2018-05-03 14:30 ` Niklas Hambüchen 2018-05-03 19:58 ` Amir Goldstein
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.