On Sun, 09.04.17 10:11, Michael Chapman (m...@very.puzzling.org) wrote: > Don't forget, they've provided an interface for software to use if it needs > more than the guarantees provided by sync. Informally speaking, the FIFREEZE > ioctl is intended to place a filesystem into a "fully consistent" state, not > just a "fully recoverable" state. (Formally it's all a bit hazy: POSIX > really doesn't guarantee anything with sync.)
If FIFREEZE is a generic ioctl() supported by a number of different file systems I figure it would be much more OK with calling it. That said, are you sure FIFREEZE is really what we want there? it appears to also pause any further writes to disk (until FITHAW is called). Which isn't really what we are interested in here (note that we return back to the initrd after the umount spree and it shall be able to do the rest, and if it actually can do that, then the file systems should be able to unmount and that usually results in writes to disk...) So, I am still puzzled why the file system people think that "sync()" isn't supposed to actually sync things to disk... I mean, it appears the call is pretty much useless and it's traditional usage (which prominently is in sysvinit before reboot()) appears to be broken by their behaviour. Why bother with sync() at all, if it implies no guarantees? This is quite frankly bullshit... It appears to me that using /boot on a file system whith such broken sync() semantics is really not a safe thing to do, and people should probably only use something more reliable, i.e. ext2 or vfat where sync() actually works correctly... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
