On 2018年08月01日 22:33, Remi Gauvin wrote: > On 2018-07-31 11:45 PM, MegaBrutal wrote: > >> I know that with nodatacow, I take away most of the benefits of BTRFS >> (those are actually hurting database performance – the exact CoW >> nature that is elsewhere a blessing, with databases it's a drawback). >> But are there any advantages of still sticking to BTRFS for a database >> albeit CoW is disabled, or should I just return to the old and >> reliable ext4 for those applications? >> > > Be very careful about nodatacow and btrfs 'raid'. BTRFS has no data > synching mechanism for raid,
Not completely the case though. Discussed in another thread, for nodatacow/nodatasum case we indeed don't have any anyway to keep data correct. But for RAID1 datacow or metadata case, it should not be case. For tree block, we have generation/first_key/level check done when searching tree blocks. And for scrub, we also have generation check, so in theory we could recovery such problem during scrub. For data, since we have cow (along with csum), it should be no problem to recover. And since datacow is used, transaction on each device should be atomic, thus we should be able to handle one-time device out-of-sync case. (For multiple out-of-sync events, we don't have any good way though). Or did I miss something from previous discussion? Thanks, Qu > so if your mirrors end up different > somehow, your Array is going to be inconsistent. >
signature.asc
Description: OpenPGP digital signature
