On Wed, 2012-05-09 at 10:58 -0700, Andy Grover wrote: > 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 :) > <nod>, I'm fine with just dropping the max_sectors attribute all-together to avoid this potential case.. Please have a look at the patch that just went out for lio-core, and will get this sorted out in for-next shortly.. Thanks for the extra feedback Andy! --nab -- 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
