[Discuss] Gluster startup, small-files performance

[Bill Bogstad]

On Wed, May 14, 2014 at 4:47 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
> Bill Bogstad wrote:
>> done.   I don't think POSIX requires this, but since most
>> filesystems seem to work this way we have gotten used to that
>> behavior.   This is why the FAQ suggests doing something like:
>
> POSIX requires it. Per the POSIX fsync() manual:
>
>>> The fsync() function shall not return until the system has completed
>>> that action or until an error is detected.

My full paragraph was:
==
Of course, as the FAQ points out many programmers assume even tighter
results from a filesystem.   i.e. That a relatively small
amount of data will be lost even if an fsync()/close() hasn't been
done.   I don't think POSIX requires this, but since most
filesystems seem to work this way we have gotten used to that
behavior.
==
I wasn't saying that  POSIX doesn't require fsync() to force data to
disk.   I was saying that POSIX says nothing about if ANY data has to
actually be saved to stable storage if
fsync()/close() has NOT been called.   Programmers/users, however, have gotten
used to the idea that if some time has passed the filesystem will have
synced much of the data anyway.  MooseFS apparently doesn't do this as
often as some other filesystems and this sometimes surprises people.

> If MooseFS does honor fsync calls correctly then this is a change more
> recent than the last time I was looking at cluster file systems.
>
> Of course, the underlying hardware can lie about its status, too, but
> that's outside of POSIX's scope.

Too true.   Let's not relive that discussion on this thread.

Bill Bogstad