On 2020/2/3 下午6:56, Skibbi wrote: > pon., 3 lut 2020 o 11:11 Qu Wenruo <quwenruo.btrfs@xxxxxxx> napisał(a): > >> It depends on the timing. >> >> In fact, as your initial report said, btrfs even succeeded to read some >> tree copy from the disk when we lost the device for a while. >> And finally goes RO if btrfs fails to write any tree blocks. > > Yeah, it wen't RO but when I tried to remount I got bad superblock bla > bla. Then that's the most important part. > And I was unable to fix this by using btrfs repair for example. btrfs check --repair is really the hardest part. In theory we shouldn't even need it, but you know that's not the reality. > I'm not sure if it possible to recover from the error I got. That's > why I'm concerned about power issues in the future. I've been using > ext4 for decades and I don't remember that fatal filesystem crash. All fses should survive power loss, obviously including btrfs. > Yeah I lost some data due to bad sectors or power loss but I was > always able to mount the filesystem. > The current conclusion is, as long as the disk follows FUA/FLUSH correctly, btrfs should provide even data consistency across power loss. (except certain known bugs in the past, which should all have been fixed) But the problem is, there seems to be some disks not following such spec, especially in consumer grade HDDs, thus sometimes it's recommended to disable write cache (aka, all writes returns when it reaches disk). If you want to be extra safe, then you can go that solution. The performance impact shouldn't be obvious, as linux page cache is handling thing really well. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
