On Mon, Aug 08, 2016 at 09:38:28PM +0300, Ivan Sizov wrote: > 2016-08-08 20:13 GMT+03:00 Chris Murphy <li...@colorremedies.com>: > > Just a wild guess, the deletions may be in the tree log and haven't > > been applied to the other trees (fs tree, extent tree, etc). So yes > > I'd expect they get deleted on a rw mount. > > > > This is what kernel? Because kernel 4.6 offers mount option > > "nologreplay" which suggests even if you do mount -r that log replay > > happens, so you shouldn't see these deleted files unless you mount ro > > *and* use nologreplay mount option. > > Live USB has kernel 4.5.7. Maybe I should try to run "btrfs rescue > zero-log" and then mount RW? Will the files safe in that case? > > > Anyway, even 5 seconds of rm -rf damages too much. If you don't have > > recent snapshots then it's not sanely salvageable, just reinstall. > > As I could see, almost all the "deleted" files are present. Certainly, > I'll make an rsync diff between two-week-ago snapshot and the current > FS state. But it will better if in-place recover without backup is > possible. > > P.S. IMHO, log replay by default is a quite dangerous thing. I didn't > know about that change and I could lose all files if the live USB had > 4.6 kernel))
Log reply on mount has _always_ been the default, and should remain so. It gives you the expected semantics after a power loss: all th efiles that you'd written up to the point of the power loss actually appear afterwards. (If this didn't happen, you could lose up to 30s of writes from before the crash). It's only very recently that there's been an option to prevent it, which is useful in a limited number of cases (such as trying to undelete a file, which is not really a supported operation in any case). Hugo. -- Hugo Mills | "I lost my leg in 1942. Some bastard stole it in a hugo@... carfax.org.uk | pub in Pimlico." http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
