All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.