On Sun, Dec 29, 2019 at 4:05 PM Alexander Veit <list@xxxxxxxxxx> wrote: > > Hi, > > btrfs restore has recovered files from a crashed partition. The command > used was > > btrfs restore -m -v /dev/sdX /dst/path/ > > without further options like -i etc. > > Are the recovered files consistent in the sense that if the file was > committed to disk and was not open during the crash, then the content of > the file would be the same as before the crash, and that damage to files > during the crash (e.g. by random writes) would result in the file not > being recovered by btrfs restore? In theory they're fine. But in practice it depends on how the application is updating those files. It's possible the updates are part of separate transactions, so some of the files may be updated and other files not updated, depending on when the crash happened. But since there are no overwrites in Btrfs (so long as the files haven't had chattr +C set), and if the hardware is honoring barriers, what should be true with a crash is that a restore recovers the most recent fully committed version of that file. For example, a directory of 50 files that somehow relate to each other, and some of them are being updated for some minutes prior to the crash, it's possible some of those files have committed updates and others don't. Some buffered writes may not get committed to stable media for several transactions, depending on the application's fsync strategy and how well tested it is. See 'man 5 btrfs' and read about flushoncommit mount option for more info. -- Chris Murphy
