On 14/08/17 16:53, Austin S. Hemmelgarn wrote: > Quite a few applications actually _do_ have some degree of secondary > verification or protection from a crash.
I am glad your applications do and you have no need of this feature. You are welcome not to use it. I, on the other hand, definitely want this feature and would have it enabled by default on all my systems despite the need for manual actions after some unclean shutdowns. > Go look at almost any database > software. It usually will not have checksumming, but it will almost > always have support for a journal, which is enough to cover the > particular data loss scenario we're talking about (unexpected unclean > shutdown). No, the problem we are talking about is the data-at-rest corruption that checksumming is designed to deal with. That is why I want it. The unclean shutdown is a side issue that means there is a trade-off to using it. No one is suggesting that checksums are any significant help with the unclean shutdown case, just that the existence of that atomicity issue does not **prevent** them being very useful for the function for which they were designed. The degree to which any particular sysadmin will choose to enable or disable checksums on nodatacow files will depend on how much they value the checksum protection vs. the impact of manually fixing problems after some unclean shutdowns. In my particular case, many of these nodatacow files are large, very long-lived and only in use intermittently. I would like my monthly "btrfs scrub" to know they haven't gone bad but they are extremely unlikely to be in the middle of a write during an unclean shutdown so I am likely to have very few false errors. They are all backed up, but without checksumming I don't know that the backup needs to be restored (or even that I am not backing up now-bad data). Graham -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
