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). > > 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 Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → https://debian-handbook.info/get/ -- 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
