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/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
