On Thu, Aug 29, 2013 at 01:37:51PM -0600, Chris Murphy wrote: > > 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)"
"... the loss of up to the last 30 seconds of successfully written data." Give the user enough information to make a sensible decision. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- emacs: Eighty Megabytes And Constantly Swapping. ---
signature.asc
Description: Digital signature
