On 10/14/2013 01:56 PM, Nicholas A. Bellinger wrote:
For two reasons primarily:
1) rtslib is 'future proofed' in such a way that new fabric modules work
without requiring any user-space changes. Alot of time and effort went
in to making things work this way, so unless code poking at configfs
takes this into account, it's likely that it will have to change every
time a new fabric module is added.
Yes, I can see this as a problem. We are only using iscsi so I don't think this will impact us much.
2) There are specific ordering requirements of how setup + teardown
works in configfs, and rtslib abstracts this away from the consumer.
For example, explicitly disabling an endpoint to force the shutdown of
all active sessions, before tearing down the LUNs, etc.
I actually think we're reaping the fallout of this as we occasionally see kernel panics on our san nodes when doing a teardown. We're aware that you need to disable the target portal group before deleting the storage object but I think we're getting into a situation where either we proceed before it's done or a concurrency issue where someone else enables it before we're finished.
- Slow performance of the shell at large scale of exports (10 minute
save/restore with thousands of targets)
So what's the bottleneck here..? Python execution performace, or
something else..?
It was something else. Using strace and strace -c we could see that targetcli was doing several times the number of syscalls strictly necessary to parse out all the configfs nodes and their values - opening and closing the same files over and over again. We wrote the skinniest code we could to simply spin through and then write the correct JSON and it allowed us to scale it up. This may have been improved now as it was a year ago that we were building this all out but the saveconfig time and slow lvm processing were the biggest challenges we had to overcome.
- We wanted perl, not python
...
What can I say? We're a perl shop. ;) Python definitely has its charms but we're way more proficient in perl.
Tregaron
--
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
