On Tue, 2014-08-12 at 15:46 -0700, Andy Grover wrote: > <aggressive snip - we're all using threaded mailreaders, right?> > > On 08/06/2014 05:22 PM, Jerome Martin wrote: > > But I feel that even though the scenario above might be not so > > problematic, maybe even contrived, there might be other cases we haven't > > though about yet leading to the same class of problem. > > > > And BTW, I do realize that targetcli could request the global lock only > > when performing an actual configfs write, instead of holding it for the > > lifetime of a session. But given the very imperative nature of 2.x > > targetcli, this means that an admin could start a series of changes that > > only make sense if they are run to completion, and then fail to acquire > > the lock again because meanwhile some script acquired the lock and > > decided to hold it forever. And in some cases, 10 minutes might feel > > like forever. Imagine a session where the admin needs to set login + > > password + ACL. Depending on the order he does it and when he gets cut > > out, this might become a problem. > > I currently favor the big-configfs-lock/quick-release (BCL) style over > fine-grained/release-whenever style. As you rightly point out, all apps > including targetcli would need to only hold the BCL across all accesses > in a single command or operation, not their entire running time. As for > the last part of the hypothetical above, all I can say is that script is > buggy, and could be killed by the admin, which would drop the lock and > allow everyone else to proceed again. > So I've been thinking about this recently, and wondering what use cases could end up being problematic with a 'BCL' approach, especially if done below the targetcli (end-user) level that end up preventing the inherent parallelism provided by existing /sys/kernel/config/target/* logic. One case that comes to mind is where a large number (say 256) of backends + fabric endpoints + LUNs are failing over from one physical host to another. Having to sequentially preform these options under the guise of a single BCL can significantly slow down the total time to recreate backends + fabric endpoints + LUNs, potentially resulting in forward facing I/O timeouts and other types of unpleasantness. This can be compounded by the amount of time it takes for hardware to re-initialize when transitioning into target mode. One example that comes to mind is with qla2xxx, where enabling target mode ends up taking 5-10 seconds per WWPN. So that said, I think there is some value in a BCL approach at the targetcli level to help avoid simple beginner mistakes for new users, but such an approach at rtslib level really limits what the kernel design was intended to do; Allowing for many outstanding operations to be executed in parallel from different processes within separate configfs group contexts. So please, let's avoid putting training wheels on rtslib that limit the underlying parallelism already built into target/configfs. --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
