On Tue, Nov 7, 2017 at 4:32 PM, Raphael Hertzog <raphael@xxxxxxxxx> wrote: > Hello, > >> Wait, I misread the information in the report and I wrongly assumed that >> pg_commit_ts is a file. It is not. it's a directory in which case, the >> inode is an overlay inode and it does have fsync f_op. >> But in the case of a lower directory that has no been copied up (which seems >> to be the case with pg_commit_ts) overlayfs will simple vfs_fsync_range the >> lower dir, so we are back to EINVAL. > > Thanks for the explanation, with this understanding I can at least create > an easy work-around (touch a file in the directory, and drop it again, > just before starting postgresql). And you won't be the first to apply that sort of workaround: http://man7.org/linux/man-pages/man1/yum-ovl.1.html > >> > to not have been be copied up here, when it would have before? >> >> That is possible, but I would need more information about all the previous >> access to directory pg_commit_ts by postgresql to figure it out. > > FWIW I reported this fsync() on a non-modified directory to PostgreSQL > developers here: > https://www.postgresql.org/message-id/20171107135454.lbelbbvfgadljmuj%40home.ouaza.com > I guess regardless of what overlayfs behavior should be, PostgreSQL developers better fix this somehow otherwise postgress upgrade is going to break for users with stable kernel. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
