On 3/6/2015 9:15 PM, Andy Grover wrote:
On 03/05/2015 11:25 PM, Bart Van Assche wrote:
On 03/05/15 19:39, Andy Grover wrote:
On 03/05/2015 08:06 AM, Bart Van Assche wrote:
If we would do what Nic proposed - modify SCST such that it uses
configfs instead of sysfs - then that would result in the removal of at
least one SCST feature that is important to its users, namely automatic
population of the configuration filesystem with hardware target port
information. Apparently Nic does not want to convert LIO from configfs
to sysfs.
Clearly configfs is here to stay, but is there anything that says LIO
couldn't have both? Besides the issue at hand, there are some other bits
of useful info in LIO that aren't available because of configfs'
limitations, but that would be possible via sysfs.
(resending my reply since apparently my previous e-mail didn't make it
to the lists)
Let's have a look at FC HBAs. Most FC HBAs have a PCIe connector and
support NPIV. If an NPIV WWN is configured then that WWN is passed from
user space to the kernel. The PCIe specification supports hot-plugging.
Although I'm not sure there exist FC HBAs that support hot-plugging,
upon hot removal of a PCIe HBA the kernel is notified of this and must
remove all NPIV WWNs from the filesystem that is used to configure the
SCSI target subsystem. Since it is not allowed to remove configfs
directories from inside the kernel I think NPIV is an example of a use
case that cannot be handled properly when using configfs for configuring
a SCSI target subsystem, even when combined in some way with sysfs.
This isn't a problem, because having a configuration for a device's WWNs
in configfs does not mean the device must be present. When the device
shows up then the target config will be used for it, and if the device
is removed the configuration no longer does anything, but still remains.
What's in configfs reflects only the config, which is why I'm wondering
if adding sysfs support might also be a good thing. sysfs would let LIO
create entries to better reflect actual running state, and be less
limited in reporting status on only "things that have config".
For example, LIO requires an ACL for all initiators but has a setting to
autogenerate these if per-ACL lun-mapping & auth is not desired. There's
no way for userspace to get a list of generated ACLs -- maybe userspace
wants to make it easy to convert generated ACLs to actual ACLs. LIO
can't create configfs nodes in-kernel and each configfs file is limited
to PAGE_SIZE so we can't just have a configfs entry that lists all of
them. That's what I was getting at above: configfs works great for
exactly what we're using it for, but there are other things sysfs does
better so we may want to use both.
That always annoyed me too. But seeing generated ACLs in sysfs while
user configured ACLs lives in configfs is weird isn't it? I'm wander if
having both sysfs/configfs interfaces might be confusing and/or messy.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
