On Thu, 2018-07-12 at 07:32 +0000, Petr Pisar wrote: > On 2018-07-11, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > The effects of fsync are impossible to see unless you hard-reboot > > the > > machine. > > Are you sure non-fsynced changes are are guaranteed to be visible on > block cache level? E.g. if you mix read/write and mmaped I/O from > different processes? In linux file writes and memory writes all hit the unified page cache so there is not difference at all, only direct io skips the page cache IIRC (but it should also invalidate it, so again no issues to applications). fsync only really make sure that what's in memory is pushed down to disk and is safely on permanent storage (which is a lie with some storage, but that is a different problem). > > I wonder if it wouldn't be more robust to use nspawn's syscall > > filter to filter the fsync calls. > > Can the syscall filter fake a success of the syscall return value? > Correctly written applications check fsync() return value and forward > the error. No, nspawn's filter just uses seccmop filters, which return EINVAL/EPERM (IIRC) on blocked arguments/syscalls So it is indeed not appropriate to use nspawn's filters to block fsync() Simo. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/JPE57JTKSNDEC7BZ6HBSITJVWGBXDCY4/
