Re: Fails to work on live images due to fsync() on pg_commit_ts before doing any write there

On Tue, 07 Nov 2017, Stephen Frost wrote:
> While I agree with this, I'm not entirely convinced that this isn't an
> issue with the implementation of the underlying filesystem after all. I
> haven't had a chance to go read those other bug reports, but my fsync()
> manpage pretty clearly seems to say that fsync should only be returning
> EINVAL if it's called on a special file (FIFO, pipe, et al). There's
> certainly no indication that it's ok for the same file to sometimes
> support fsync() and other times *not* support fsync(). That's pretty
> bizarre.

The manpage shows "EROFS" on the same line as "EINVAL", and "EROFS" stands
for "Read-Only FileSystem". So it seems to be normal for read-only
filesystems to return errors (arguably squashfs returns EINVAL and
it would have been better to use EROFS).

And overlayfs, by its nature, is made to forward file system calls
to different underlying filesystems (that thus have different
characteristics).

That said I agree that overlayfs should be smarter and it should hide
EROFS/EINVAL on fsync() when it knows that the call is delegated to a
read-only filesystem.

Still I believe that this issue should be fixed in both sides. It's not
smart from PostgreSQL to call fsync() when it has not made any change.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/