Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
От | Raphael Hertzog |
---|---|
Тема | Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there |
Дата | |
Msg-id | 20171107144727.m6w4psl5kwm2p7jl@home.ouaza.com обсуждение исходный текст |
Ответы |
Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: