On 05/08/2012 09:54 PM, Nicholas A. Bellinger wrote: > So the issue of concern here is with existing userspace code that is > using this value to explicitly set max_sectors at target restart time > based upon the original blkdev queue limits (or smaller) with IBLOCK, > and can possibly end up rejecting incoming I/O if the max_sectors is set > too small. > > Considering we are still enforcing an fabric_max_sectors default value > of 8192 ahead of the max_sectors check, I think it makes sense to just > use max_hw_sectors instead here for all backends, and eventually turn > max_sectors into read-only attr and/or drop its usage entirely in the > future.. Nick, What is stopping us from dropping the max_sectors attribute now? The shellscript that lio-utils emits should not fail to restore other settings if attribs/max_sectors is not present, and rtslib-fb handles this too. Just trying to make less work for you :) Regards -- Andy -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
