I agree.  This would be a very convenient way to organize storage data 
that currently must be obtained from various discrete CLI commands.

-Peter

Engle, Victor wrote:
> What a great proposal! To be able to simply browse a directory structure
> rather than try and remember the usage for a handful of tools would
> really make it easy for a systems administrator to quickly get a picture
> of exactly what the host sees wrt storage.
>
> It would also be nice if the pseudo file system would represent mpxio.
> Possibly with a directory structure with the scsi_vhci device as a top
> level directory with subdirectories representing primary, secondary and
> standby paths, each with properties files. 
>
> Regards,
>
> Vic Engle
>
>
> -----Original Message-----
> From: Harihara Kadayam [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 18, 2007 10:04 PM
> To: [email protected]
> Subject: [storage-discuss] Project proposal for SCSI SAM File system
>
> I would like propose a new project SCSI SAM Pseudo File system in
> OpenSolaris. This file system will be somewhat similar to Linux's
> /proc/scsi file system, with several extensions.
>
> In a typical setup, we have multiple systems connected to the storage
> devices and each could have multiple initiators/HBAs (SCSI, FC or
> iSCSI), which in turn have multiple ports, targets and luns. Each of
> these entities and its properties can be represented as files and
> directories.
>
> Features of this file system
> The SCSI SAM file system can have the following features. The list here
> is very limited and can be modified after review.
>
> 1)    All SCSI components in the SCSI architecture model (SAM) to be
> listed as files and directories.
> 2)    Vendor HBA card properties
> 3)    Vendor private data (VPD), NVRAM, FW updates
> 4)    Adapter command interface
> 5)    Target and LUN properties
> 6)    Switch properties (for FC)
>
> Overview:
> If this file system is mounted on /system/scsidev/localhost for local
> machine, then that directory will have sub-directories of all the HBA or
> iSCSI initiators present in the system. Under the HBA directory, it will
> have sub-directories representing every port in the HBA. Port
> directories will have a list of target sub-directories, which in-turn
> has LUN sub-directories. The LUN sub directory has a file "lun" which
> contains the raw LUN.
>
> Apart from just these directories, this file system will have following
> additional files:
>
> Props file:
> Under every directory in this file system, a props file will be present.
> This props file will have all the properties of that particular
> directory
>
> Following are the props file contents for each directory
> a)    /system/scsidev/localhost: Details about the system,
> architecture etc.
> b)    HBA directory: Details about the card, vendor, device id,
> controlling driver name, FW version number, type of boot code, subsystem
> id, device id etc. 
> c)    Port directory: Port WWN or id number, port speed, port state
> target count etc. 
> d)    Target directory: Target's inquiry data, its port number (WWN)
> etc
> e)    Lun directory: Lun properties like lun state, lun number etc
>
> NVRAM, VPD, Firmware data:
> The NVRAM image, VPD data, FW image, BIOS will be represented as files
> under the HBA directory for each HBA. The VPD or NVRAM image can be
> obtained using cat command. Update of FW or other image can be done as a
> file I/O itself.
> Adapter Command Interface (cmd_port):
> Each of the directories will have cmd_port apart from the props file.
> This is a write only file through which commands to that layer will be
> sent. 
>
> For example to reset the adapter chip the command could be:
> echo reset > /system/scsidev/localhost/QLA2462/cmd_port
>
> To send inquiry command to a lun2
> echo scsi inquiry>
> /system/scsidev/localhost/QLA2462/target1/lun2/cmd_port
>
> Extensions:
> Fibre Channel Switches:
> The Fibre Channel switches directory could be included under the port
> directory. This represents the FC switch and properties of port under
> the switch.
>
> Remote systems' properties:
> The whole file system structure could be mounted into a remote machine,
> provided with appropriate security credentials and interoperability with
> NFS file system.
>
> So the directory /system/scsidev/localhost will have the following
> entries
>
> cmd_port
> props
> QLA2432/
> QLA2432/port0
> QLA2432/port0/props
> QLA2432/port0/cmd_port
> QLA2432/port0/target0/
> QLA2432/port0/target0/props
> QLA2432/port0/target0/cmd_port
> QLA2432/port0/target0/lun0
> QLA2432/port0/target0/lun0/props
> QLA2432/port0/target0/lun0/cmd_port
> QLA2432/port0/target0/lun0/lun
> and so on
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
>   

_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to