20.07.2018 20:16, Goffredo Baroncelli пишет: > On 07/20/2018 07:17 AM, Andrei Borzenkov wrote: >> 18.07.2018 22:42, Goffredo Baroncelli пишет: >>> On 07/18/2018 09:20 AM, Duncan wrote: >>>> Goffredo Baroncelli posted on Wed, 18 Jul 2018 07:59:52 +0200 as >>>> excerpted: >>>> >>>>> On 07/17/2018 11:12 PM, Duncan wrote: >>>>>> Goffredo Baroncelli posted on Mon, 16 Jul 2018 20:29:46 +0200 as >>>>>> excerpted: >>>>>> >>>>>>> On 07/15/2018 04:37 PM, waxhead wrote: >>>>>> >>>>>>> Striping and mirroring/pairing are orthogonal properties; mirror and >>>>>>> parity are mutually exclusive. >>>>>> >>>>>> I can't agree. I don't know whether you meant that in the global >>>>>> sense, >>>>>> or purely in the btrfs context (which I suspect), but either way I >>>>>> can't agree. >>>>>> >>>>>> In the pure btrfs context, while striping and mirroring/pairing are >>>>>> orthogonal today, Hugo's whole point was that btrfs is theoretically >>>>>> flexible enough to allow both together and the feature may at some >>>>>> point be added, so it makes sense to have a layout notation format >>>>>> flexible enough to allow it as well. >>>>> >>>>> When I say orthogonal, It means that these can be combined: i.e. you can >>>>> have - striping (RAID0) >>>>> - parity (?) >>>>> - striping + parity (e.g. RAID5/6) >>>>> - mirroring (RAID1) >>>>> - mirroring + striping (RAID10) >>>>> >>>>> However you can't have mirroring+parity; this means that a notation >>>>> where both 'C' ( = number of copy) and 'P' ( = number of parities) is >>>>> too verbose. >>>> >>>> Yes, you can have mirroring+parity, conceptually it's simply raid5/6 on >>>> top of mirroring or mirroring on top of raid5/6, much as raid10 is >>>> conceptually just raid0 on top of raid1, and raid01 is conceptually raid1 >>>> on top of raid0. >>> And what about raid 615156156 (raid 6 on top of raid 1 on top of raid 5 on >>> top of....) ??? >>> >>> Seriously, of course you can combine a lot of different profile; however >>> the only ones that make sense are the ones above. >> >> RAID50 (striping across RAID5) is common. > > Yeah someone else report that. But other than reducing the number of disk per > raid5 (increasing the ration number of disks/number of parity disks), which > other advantages has ?
It allows distributing IO across virtually unlimited number of disks while confining failure domain to manageable size. > Limiting the number of disk per raid, in BTRFS would be quite simple to > implement in the "chunk allocator" > You mean that currently RAID5 stripe size is equal to number of disks? Well, I suppose nobody is using btrfs with disk pools of two or three digits size. -- 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
