Vladislav Bolkhovitin, on 11/16/2010 04:17 PM wrote: > Your questions are very good, so let's summarize what we need to serve > the needs of a SCSI target subsystem (not necessary SCST) and see what > can fit them. > > So, the needs: > > 1. Be capable to represent to user space internal configuration to let > user space be able to see and analyze it, including various statistics. > > 2. Let user space manage the internal configuration. > > 3. Desired: possibility to send to user space events about important > internal actions, like I/O failures, which may need user space > intervention to recover, like switching from active to passive role in a > cluster. > > So, what can we do with ConfigFS: > > (1): Only partially, because by design ConfigFS isn't supposed to > represent internal configuration, it can only manage it. Extending > ConfigFS to be capable to do that would be, in my understanding, a > strong violation of its purpose and, hence, design and if went this way > eventually ConfigFS would become just a duplication of the SYSFS > functionality. > > (2): ConfigFS can do that. This is exactly for what it was designed and > implemented. But in this particular application it would have some > limitations derived from (1): to manage harware-related entries a user > should magically know from somewhen names of those entries to create > them by "mkdir" command. > > For instance, consider a user has a Fibre Channel HBA and want to use it > in the target mode. Before he can configure it, he should somehow know > its ports names and for each of them run: > > # mkdir /sys/kernel/config/.../50:50:00:00:00:00:00:11 > # mkdir /sys/kernel/config/.../50:50:00:00:00:00:00:12 > ... > > where 50:50:00:00:00:00:00:1x are the ports' names. Only after that > those ports appear on the ConfigFS and can be managed. > > (3): No events at all. > > Now consider SYSFS: > > (1): Easily. This is exactly for what it was designed and implemented. > > (2): Possible without any limitations and side effects. > > (3): Also possible. > > So, why not use SYSFS if it suits all the needs _without_ any additional > effort and patches? > > Other alternatives? A set of custom IOCTLs? One more configuration FS? I > believe, those would be quite disgusting for all. > >> Maybe I misunderstand - But if both sides have merit then wouldn't a >> compromise be appropriate? >> >> Maybe the sensical compromise is to use sysfs code to create a new >> namespace that would fit this purpose? It seems that I am also >> hearing that the alternatives to sysfs aren't always adequate - so >> why not use sysfs, but have a place where it's appropriate to use it? > > This is exactly what we are proposing: to use SYSFS in additional > namespace /sys/kernel/scst_tgt. > > As far as I can see, only Greg is against it. Greg keeps his reasons > private, so I can only guess that Greg is against extending usage of > SYSFS (note, _usage_, not implementation! Everything needed long ago > implemented.) beyond the scope it was originally designed around 10 > years ago. But SYSFS is already widely used this way in the kernel, as > Joe illustrated, hence there is demand for it. People need it. So, why > not to just acknowledge this fact and go ahead the simplest and most > useful for both users and developers way? Since nobody objected, Greg, could you consider to ACK SCST SYSFS management interface in /sys/kernel/scst_tgt/, please? Please find the SCST SYSFS ABI documentation file you requested below. We are also preparing a new patch to free our objects in kobjects.release() without explicit x_initialized flags as you requested. Thank you for your effort, Vlad Documentation/ABI/testing/sysfs-scst: What: /sys/kernel/scst_tgt/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains SCST management interface entries. What: /sys/kernel/scst_tgt/devices/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains subdirectories for all SCST devices What: /sys/kernel/scst_tgt/devices/<device>/exported/exportX Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Links to LUNs in the LUNs group where <device> exported, e.g. to /sys/kernel/scst_tgt/targets/iscsi/iqn.2006-10.net.vlnb:tgt/luns/11 What: /sys/kernel/scst_tgt/devices/<device>/handler Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Link to dev handler of this device, if assigned, e.g. to /sys/kernel/scst_tgt/handlers/dev_disk What: /sys/kernel/scst_tgt/devices/<device>/type Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: SCSI type of this device as define by SAM. What: /sys/kernel/scst_tgt/handlers/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains all SCST dev handlers. What: /sys/kernel/scst_tgt/handlers/<handler>/<device> Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Links to <device> managed by this dev handler, e.g. ext3_disk1_4K -> /sys/kernel/scst_tgt/devices/ext3_disk1_4K What: /sys/kernel/scst_tgt/handlers/<handler>/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Management entry, which allows to create and delete devices for this dev handler. See SysfsRules file for more info. What: /sys/kernel/scst_tgt/handlers/<handler>/type Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: SCSI type of this dev handler as define by SAM. What: /sys/kernel/scst_tgt/sgv/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains SCST SGV caches statistics. What: /sys/kernel/scst_tgt/sgv/global_stats Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains global SGV cache statistics. What: /sys/kernel/scst_tgt/sgv/<cache>/stats Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains statistics for SGV cache <cache> What: /sys/kernel/scst_tgt/targets/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains all SCST target drivers What: /sys/kernel/scst_tgt/targets/<target_driver> Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains all targets for <target_driver> What: /sys/kernel/scst_tgt/targets/<target_driver>/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Optional management entry, which allows to create and delete targets for this target driver. See SysfsRules file for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/enable Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Optional attribute to enable <target_driver> and make it serve incoming connections from initiators. Possible values: 1 - enable 0 - disable What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/ Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Contains security groups for <target> What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to create and delete security groups for <target>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/initiators/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to add and delete initiators to/from <group>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/initiators/<initiator_name> Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: One or more initiators in <group>. Contains initiator's name. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/luns/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to add and delete LUNs to/from <group>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/luns/<lun>/device Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Link to device for <lun>, e.g. to /sys/kernel/scst_tgt/devices/ext3_disk1_4K What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/luns/<lun>/read_only Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets if this LUN should be read only What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/addr_method Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets SCSI addressing method for <group>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/cpu_mask Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets CPU mask for threads serving initiators in <group>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/io_grouping_type Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets IO grouping types for threads serving initiators in <group>. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/luns/mgmt Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to add and delete LUNs to/from the <target>'s default set of LUNs. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/luns/<lun>/device Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Link to device for <lun>, e.g. to /sys/kernel/scst_tgt/devices/ext3_disk1_4K What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/luns/<lun>/read_only Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets if this LUN should be read only What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/addr_method Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets SCSI addressing method for the <target>'s default set of LUNs. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/cpu_mask Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets CPU mask for threads serving initiators in the <target>'s default set of LUNs. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/io_grouping_type Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Sets IO grouping types for threads serving initiators in the <target>'s default set of LUNs. See README.scst for more info. What: /sys/kernel/scst_tgt/targets/<target_driver>/<target>/enable Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Optional attribute to enable <target> and make it serve incoming connections from initiators. Possible values: 1 - enable 0 - disable What: /sys/kernel/scst_tgt/last_sysfs_mgmt_res Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Returning completion status of the last management command. See README.scst for more info. What: /sys/kernel/scst_tgt/setup_id Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to read and write SCST setup ID. This ID can be used in cases, when the same SCST configuration should be installed on several targets, but exported from those targets devices should have different IDs and SNs. For instance, VDISK dev handler uses this ID to generate T10 vendor specific identifier and SN of the devices. What: /sys/kernel/scst_tgt/threads Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to read and set number of global SCST I/O threads. Those threads used with async. dev handlers, for instance, vdisk BLOCKIO or NULLIO What: /sys/kernel/scst_tgt/version Date: November 2010 Contact: Vladislav Bolkhovitin <vst@xxxxxxxx> Description: Allows to see version of SCST and enabled optional features. -- 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
