On Sun, Apr 9, 2017 at 2:17 PM, Lennart Poettering <lenn...@poettering.net> wrote:
> 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... > It does? My /boot is vfat due to UEFI requirements, and it becomes unbootable if you as much as sneeze near it – I've already had to repair it thrice, after a sync and everything. -- Mantas Mikulėnas <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
