This is all clear. My question referes to "use the lower devid disk containing the stripe"
2018-01-31 10:01 GMT+01:00 Anand Jain <anand.j...@oracle.com>: > When a stripe is not present on the read optimized disk it will just > use the lower devid disk containing the stripe (instead of failing back > to the pid based random disk). Use only one disk (the disk with the lowest devid that containing the stripe) as fallback should be not a good option imho. Instead of it should still be used the pid as fallback to distribute the workload among all available drives. [stripe to use] = [preffer stripes present on read_mirror_policy devids] > [fallback to pid % stripe count] Perhaps I'm not be able to express myself in English or did I misunderstand you? 2018-01-31 15:26 GMT+01:00 Anand Jain <anand.j...@oracle.com>: > > > On 01/31/2018 06:47 PM, Peter Becker wrote: >> >> 2018-01-31 10:01 GMT+01:00 Anand Jain <anand.j...@oracle.com>: >>> >>> When a stripe is not present on the read optimized disk it will just >>> use the lower devid disk containing the stripe (instead of failing back >>> to the pid based random disk). >> >> >> Is this a good behavior? beause this would eliminate every performance >> benefit of the pid base random disk pick if the requested stripe is >> not present on the read optimized disk. >> Wouldn't it be better to specify a fallback and use the pid base >> random pick as default for the fallback. >> >> For example: >> >> RAID 1 over 4 disk's >> >> devid | rpm | size >> ------------------------ >> 1 | 7200 rpm | 3 TB >> 2 | 7200 rpm | 3 TB >> 3 | 5400 rpm | 4 TB >> 4 | 5400 rpm | 4 TB >> >> mount -o read_mirror_policy=1,read_mirror_policy=2 >> >> Cases: >> 1. if the requested stripe is on devid 3 and 4 the algorithm should >> choise on of both randomly to incresse performance instead of read >> everytime from 3 and never from 4 >> 2. if the requested stripe is on devid 1 and 3, all is fine ( in case >> of the queue deep of 1 isn't mutch larger then the queue deep of 3 ) >> 3. if the requested stripe is on devid 1 and 2, the algorithm should >> choise on of both randomly to incresse performance instead of read >> everytime from 1 and never from 2 > >> >> >> And all randomly picks of a device should be replaced by a heuristic >> algorithm wo respect the queue deep and sequential reads in the >> future. > > > This scenario is very well handled by the pid/heuristic based > read load balancer, pid based read load balancer is by default still, > Tim has written IO load based read balancer which can be set using > this mount option when all integrated together, and it needs > experiments to see if it can be by default replacing the pid method. > Further as of now we don't do allocation grouping, so if you have two > ssd and two hd in a RAID1 its not guaranteed that allocation will > always span across a SSD and a HD, so there is bit of randomness > in the allocation itself. > > Thanks, Anand -- 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
