On Fri, Oct 14, 2016 at 3:38 PM, Chris Murphy <li...@colorremedies.com> wrote: > On Fri, Oct 14, 2016 at 1:55 PM, Zygo Blaxell > <ce3g8...@umail.furryterror.org> wrote: > >> >>> And how common is RMW for metadata operations? >> >> RMW in metadata is the norm. It happens on nearly all commits--the only >> exception seems to be when both ends of a commit write happen to land >> on stripe boundaries accidentally, which is less than 1% of the time on >> 3 disks. > > In the interest of due diligence, and the fact I can't confirm or deny > this myself from reading the code (although I do see many comments > involving RMW in the code), I must ask Qu if he can corroborate this. > > Because basically means btrfs raid56 is not better than md raid56 - by > design. It has nothing to do with bugs. This is substantially worse > than the scrub->wrong parity bug. > > Does it make sense to proscribe raid5 profile for metadata? As in, > disallow -m raid5 at mkfs time? Maybe recommend raid1. Even raid6 > seems like it could be specious - yes there are two copies but if > there is constant RMW, then there's no CoW and we're not really > protected that well with all of these overwrites, statistically > speaking. > > Basically you have to have a setup where there's no chance of torn or > misdirected writes, and no corruptions, in which case Btrfs checksums > aren't really helpful, you're using it for other reasons (snapshots > and what not). > > Really seriously the CoW part of Btrfs being violated by all of this > RMW to me sounds like it reduces the pros of Btrfs.
Also, is there RMW with raid0, or even raid10? Or is that always CoW for metadata and data, just like single and dup? If raid0 is always CoW, then I don't think it's correct to consider raid5 minus parity to be anything like raid0 - in a Btrfs context anyway. Outside of that context, I understand the argument. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
