On 2019/12/30 上午6:58, Alexander Veit 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, Normally crash shouldn't corrupt btrfs, it's either btrfs bug or something else causing corruption. > and that damage to files > during the crash (e.g. by random writes) would result in the file not > being recovered by btrfs restore? The restore doesn't check data csum. And by default it reads the first copy of data. If the read succeeded, btrfs-restore just call it a day, thus no data csum verification or anything else. So it's not as good as you would expect. Anyway, btrfs-restore is the last resort method, before that RO mount and various rescue mount options should be tried before it. Kernel will always verify data csum. Thanks, Qu > > I could not find a clear statement about this in the man page or the > btrfs wiki. > > # uname -a > Linux healer 5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64 > GNU/Linux > > # btrfs --version > btrfs-progs v5.4 > > The btrfs file system had been created in a system with a Linux 4.19.72 > kernel. >
Attachment:
signature.asc
Description: OpenPGP digital signature
