Project

General

Profile

Documentation #24641

Document behaviour of fsync-after-close

Added by Niklas Hambuechen 10 months ago. Updated about 1 month 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 10 months ago

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

#2 Updated by Zheng Yan 10 months ago

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

#3 Updated by Niklas Hambuechen 10 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?

#4 Updated by Patrick Donnelly about 1 month ago

  • Target version changed from v14.0.0 to v15.0.0

Also available in: Atom PDF