On Dec 29, 2013, at 5:39 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > Yes, it does turn off checksumming as well as COW, but given the write- > into scenario, that's actually best anyway, because otherwise btrfs has > to keep updating the checksums On second thought, I'm less concerned with bitrot and checksumming being lost with nodatacow, than I am with significantly increasing the chance the journal is irreparably lost due to corruption during an unclean shutdown. > But in all these cases, it's also quite common for the application doing > the writing to have its own checksumming/error-detection and possible > correction -- it pretty much comes with the territory -- in which case > btrfs attempting to do the same is simply superfluous even if it weren't > a race-condition trigger. I don't know what kind of checksumming systemd performs on the journal, but whenever Btrfs has found corruption with the journal file(s), systemd-journald has also found corruption and starts a new log. So it makes sense to rely on its own mechanisms, than Btrfs's. > And I'm predicting that since btrfs is the assumed successor to the ext* > series as the Linux default filesystem, and systemd is targeting Linux > default initsystem status as well, it's only logical that at some point > systemd will detect what filesystem it's logging to, and will > automatically set NOCOW on the journal file when that filesystem is > btrfs. Is this something that should be brought up on the systemd-devel@ list? Or maybe file it as an RFE against systemd at freedesktop.org? Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
