[LU-646] clarification of lustre fsync behavior

Tue, 29 Apr 2014 22:12:07 +0000

NASA is asking for clarification of fsync(2) behavior with lustre.

I'll ask the general question and then break it into two parts as we believe there is a bug in one
part.

Firstly, When a user issues an fsync(2) on a regular file descriptor in their code, we do not get a
successful response unless the underlying device, be it a disk or a raid controller(possibly with
battery backed up cache) has received the write and put it either on disk or has it safely in
batter backed up cache. Correct?

Secondly, when an fsync is issued on a directory file descriptor, from the man page:

"Calling fsync() does not necessarily ensure that the entry in the directory containing the
file has also reached disk. For that an explicit fsync() on a file descriptor for the
directory is also needed."

I would assume this does not mean file metadata, correct?

When fsync is called on a directory in a lustre file system we do not get the expected result like
we do for ext3, ext4, or xfs.

Whamcloud Community JIRA

[LU-646] clarification of lustre fsync behavior