Re: [PATCH v5 07/12] md: support to align bio to limits
Christoph Hellwig <[email protected]>
| Newsgroups | gmane.linux.raid |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jan 19, 2026 at 03:43:34PM +0800, Yu Kuai wrote: > >> 64k boundary is still necessary for small IO. > > What do you mean with "necessary for small IO"? > > io_min and io_opt is quite similar in mdraid, IO aligned with io_opt > can get the best bandwidth, and IO aligned with io_min can get the > best iops. Currently chunk_sectors is the same as io_min, and > bio_split_rw() will try to align IO to io_min. I don't think we want > to remove this behavior. I'm still confused. Let's go back to your example: 32 disks raid5 array with chunksize=64k. Let's look at writes first: Each I/O that is full aligned to 31 * 64k can be handled without a read-modify-write cycle, so splitting I/O at that boundary makes perfect sense. Below that there really should not me much difference, i.e. splitting anything at the 64k boundary is not useful. So you want the chunk_sectors to apply at the 31 * 64k boundary, and the io_opt as well. And probably io_min too. (all just looking at writes). For non-degradead reads, not much should matter. All reads should be reasonably efficient, splitting 64k boundaries is going to make the implementation trivial, but will make your rely heavily on plugging below, and also means you use quite a lot of lower bios. For degraded reads, each I/O will always read 31 * 64k. Splitting at 31 * 64k makes the implementation much easier. I guess you want different boundaries for reads and writes? Note that io_opt and io_min really just are values for the caller and not affect splitting decisions themselves. Of course the underlying factors should be related.