On 2020/9/21 22:00, Christoph Hellwig wrote: > On Mon, Sep 21, 2020 at 05:54:59PM +0800, Coly Li wrote: >> I am not sure whether virtual bcache device's optimal request size can >> be simply set like this. >> >> Most of time inherit backing device's optimal request size is fine, but >> there are two exceptions, >> - Read request hits on cache device >> - User sets sequential_cuttoff as 0, all writing may go into cache >> device firstly. >> For the above two conditions, all I/Os goes into cache device, using >> optimal request size of backing device might be improper. >> >> Just a guess, is it OK to set the optimal request size of the virtual >> bcache device as the least common multiple of cache device's and backing >> device's optimal request sizes ? > > Well, if the optimal I/O size is wrong, the read ahead size also is > wrong. Can we just drop the setting? > I feel this is something should be fixed. Indeed I overlooked it until you point out the issue now. The optimal request size and read ahead pages hint are necessary, but current initialization is simple. A better way might be dynamically setting them depends on the cache mode and some special configuration. By your inspiration, I want to ACK your original patch although it doesn't work fine for all condition. Then we may know these two settings (ra_pages and queue_io_opt) should be improved for more situations. At lease for most part of the situations they provide proper hints. How do you think of the above idea ? Coly Li -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel