On Mon, Nov 07 2016 at 9:46pm -0500, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > Mike, > > Mike> You're suggesting that when the DM multipath device's limits are > Mike> stacked up from the underlying devices: cap the mpath's > Mike> max_hw_sectors to the underlying devices' max_sectors? > > That will break SG_IO, firmware upgrades, etc. (things you probably > shouldn't do on the MP device in the first place but which users often > do). > > However, doesn't it make more sense to tweak limits on DM device instead > of the underlying ones? It seems a bit counter-intuitive to me to change > max_sectors_kb on a different device than the one where the filesystem > whose max I/O size you want to change is located. As you know, the limits are stacked from the bottom-up. > I guess this brings us back to the desire to be able to restack the > limits at will when something changes somewhere... Tough to do that in a race-free way when DM multipath requests are cloned for submission to the underlying devices. As the commit header from this thread mentioned, what I've arrived at is to have multipathd establish a desired max_sectors_kb (if configured to do so in multipath.conf) on the underlying paths _before_ the multipath device is created. Yet to check with Ben Marzinski or others but it seems like a reasonable feature (and really the cleaniset way to deal with this issue IMHO.. no need for lots of kernel code changes for something so niche). -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
