Some things to think about: 1. What is the scope of this file system ? Does it stop at HBA driver level or it goes deeper e.g. for a technology like Fibre channel, does the file system only stays at SCSI HBA level (which is fcp in this case) or it goes down to fibre channel stack as well. Does it stop there ? e.g. for technologies like FCoE and iscsi, does it go all the way to the ethernet card driver ? If yes then is the scope really limited to storage or expands to networking also ? If yes, then is it an attempt to create yet another /dev tree ?
2. To accomplish something like this, I think every storage component participate. This includes, target driver, HBA drivers, FCA drivers, various storage related frameworks (leadville, SRP, scsa2usb etc.) A lot of these components are developed and maintained by non-SUN vendors. And some of those vendors wont participate (or wont participate right away). So how will a hybrid environment will be handled specially in a multipathed configuration ? 3. All the components listed above already have /devices and /dev/ entries. So what will happen to those entries. Should they be removed ? But then there are tools and scripts which depend upon those entries. 4. Looking at all of the above this looks like a lot of work. So the final thing that comes to mind is: what is the real purpose ? Is it observability ? if so then I dont think people are going to manually browse through the directories and files to get the data they need specially in a multipathed environment. As far as I am aware of, most administrators use tools and scripts for the same purpose. So as an earlier post on this subject also suggested, a more consolidated toolset, or GUIs, or API or all of those are probably a better solution. This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
