> On Jul 12, 2018, at 4:26 AM, Simo Sorce <simo@xxxxxxxxxx> wrote: > >> 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() Seccomp can be used to block a syscall and fake a return value of 0 (success) or any error code chosen by the filter. I assume systemd exposes this functionality. _______________________________________________ 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/HKZQG4BJ4RRVVHOAI5GOJYG3DCZVRARE/
