Project

General

Profile

Documentation #24641

Document behaviour of fsync-after-close

Added by Niklas Hambuechen 6 months ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Category:
-
Target version:
Start date:
06/24/2018
Due date:
% Done:

0%

Tags:
Backport:
Reviewed:
Affected Versions:
Labels (FS):
Pull request ID:

Description

The following should be documented:

Does close()/re-open()/fsync() provide the same durability and visibility-to-other-clients guarantees as fsync()/close() does?

POSIX leaves that open; for many local file systems the answer is "yes" (but modulo bugs; even the very recent Linux v4.17 had some issues with that).

The coreutils "sync" utility now also accepts single files as arguments, and does open()+fsync(); the answer to the above question would determine wither this will work reliably on CephFS.

For more details see: https://stackoverflow.com/questions/37288453/calling-fsync2-after-close2

It would be great to know the answer for CephFS, and have it documented.

History

#1 Updated by Patrick Donnelly 6 months ago

  • Assignee set to Patrick Donnelly
  • Target version set to v14.0.0

#2 Updated by Zheng Yan 6 months ago

they are the same. In cephfs, there is no dirty data/metadata associated with file handle.

#3 Updated by Niklas Hambuechen 6 months ago

Great, that certainly makes things easier from the application perspective.

It would be great if we could write it down in the docs, perhaps http://docs.ceph.com/docs/mimic/cephfs/posix/ is a good place?

Also available in: Atom PDF