Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-646

clarification of lustre fsync behavior

    XMLWordPrintable

Details

    • 3
    • 23,485
    • 4871

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              laisiyao Lai Siyao
              laisiyao Lai Siyao
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: