On Aug 29, 2013, at 11:35 AM, Zach Brown <[email protected]> wrote: >> If those fail, then look in dmesg for errors relating to the log >> tree -- if that's corrupt and can't be read (or causes a crash), use >> btrfs-zero-log. > > In a bit of a tangent: > > btrfs-zero-log throws away data that fsync/sync could have previously > claimed was stable on disk. > > Given how often this is thrown around as a solution to a broken > partition, should the tool jump up and down and make it clear that it's > about to roll the file system back? This seems like relevant > information. > > Right now, as far as I can tell, it's completely undocumented and > silent.
Yes, I think it helps remove some burden on the list answering questions about a tool that doesn't have any documentation, to have a warning. How much longer will btrfs-zero-log be needed? If whatever it's doing isn't obviated by future improvements to btrfsck, and this sort of big hammer approach is still needed in some worse case scenarios, then it probably hurts no one to flag the user with essentially how you described it. I think documentation is a greater burden to create, and less likely to be consulted. "Proceeding will roll back the file system to a previous state, and may cause the loss of successfully written data. Proceed? (Y/N)" Alternative language could include a suggestion or reminder of what should be tried before proceeding, if applicable. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
