> 2021年06月06日 06:38，antlists <antlists@xxxxxxxxxxxxxxx> 写道： > > On 05/06/2021 21:54, Wang Shanker wrote: >> You may wonder the importance of merging discard operations. In the >> implementation of RAID456, bios are committed in 4k trunks (they call >> them as stripes in the code and the size is determined by DEFAULT_STRIPE_SIZE). >> The proper merging of the bios is of vital importance for a reasonable >> operating performance of RAID456 devices. > > Note that I have seen reports (I'm not sure where or how true they are), that even when requests are sent as 512k or whatever, certain upper layers break them into 4k's, presumably expecting lower layers to merge them again. Yes, that's true for RAID456. RAID456 is issuing 4k size requests to lower backing device, no matter how large the request received is. That's won't be a problem because for normal read and write operations, those 4k size requests can be nicely merged into larger ones. Otherwise, we would be flooded with reports complaining about unacceptable performance of raid456. > You might have better luck looking for and suppressing the breaking up of large chunks. I'm quite aware that it is raid456 that is breaking the requests. It might be better if we can avoid this in raid456. I believe it can be very difficult due to the design of raid456 code. However, the question now is the merging is successful for normal read/write operations, but failed for discard operations. Where lies the difference? I did some testing in a qemu vm and added some debug printing in the control flow. By what I have discovered, I'm quite confident that the discard requests are not processed the right way when merging them. Cheers, Miao Wang
