> Il giorno 18 dic 2018, alle ore 18:22, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto: > > > >> Il giorno 18 dic 2018, alle ore 17:41, Tejun Heo <tj@xxxxxxxxxx> ha scritto: >> >> Hello, Paolo. >> >> On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote: >>> If Tejun cannot see any solution to his concern, then can we just >>> switch to this extension, considering that >>> - for non-shared names the interface is *identical* to the current >>> one; >>> - by using this new interface, and getting feedback we could >>> understand how to better handle Tejun's concern? >>> A lot of systems do use weights, and people don't even know that these >>> systems don't work correctly in blk-mq. And they won't work correctly >>> in any available configuration from 4.21, if we don't fix this problem. >> >> So, when seen from userland, how it should behave isn't vague or >> complicated. For a given device and policy type, there can be only >> one implementation active. > > Yes, but the problem is the opposite. You may have > - two different policies, with the same interface parameter, > - one active on one device > - the other one active on another device > > In that case, statistics from one policy necessarily differ from > statistics from the other policy. > > In this respect, in a system with more than one drive it already > happens that the same policy is active on different devices. When > printing a statistics interface file for the policy, the output will > be a list of separate statistics, with a bunch of statistics *for > each* drive (plus a grand total in some cases). > > So, our proposal simply extends this scheme in the most natural way: > if, now, also two or more policies share the same statistics file, > then the output will be a list of separate statistics, one for each > policy. The statistics for each policy will be tagged with the policy > name, and will have the same identical form as above. It seems the > most natural hierarchical extension of the same scheme. > > At any rate, if you don't like it, just tell us how you prefer it > done. Do you prefer the sharing of statistics file to be simply > forbidden? (If this can be done.) I think such an incomplete solution > would preserve part of the current mess; but, if this allows us to > exit from this impasse, then it is ok for me. > > *Any* feasible option is ok for me. Just pick one. > >> It doesn't make sense to have two weight >> mechanisms active on one device, right? > > (Un)fortunately, the problem are not weights. There won't be two > weights for two policies expiring a weight parameter. The problems s/expiring/sharing sorry
