On Sun, 09.04.17 22:37, Chris Murphy ([email protected]) wrote: > Oh god - that's the opposite direction to go in. There's not even > pretend crash safety with those file systems. If they're dirty, you > must use an fsck to get them back to consistency. Even if the toy fs > support found in firmware will tolerate the inconsistency, who knows > what blocks it actually ends up loading into memory, you can just get > a crash later at the bootloader, or the kernel, or initramfs. That so > much consumer hardware routinely lies about having committed data to > stable media following sync() makes those file systems even less > reliable for this purpose. Once corrupt, the file system has no fail > safe or fallback like a journaled or COW file system. It's busted > until fixed with fsck.
Well, note that in a systemd world where systemd manages the ESP there's a pretty good chance the file system stays in a clean state, since we unmount it after after 2s after each write, and only make it available via autofs. So yeah, only in a short time frame around a boot loader update there's a chance for corruption. Which is certainly much better than a corruption on every disk change like on XFS... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
