It seems like the fundamental question for this project is: If we had a magic wand that could bring this new filesystem into existence would we be better off with it or without it? The implementation effort and impacts on other subsystems are secondary concerns that might preclude an actual implementation (or not!)
I'm sure Harihara will want to answer the points you've raised but one quick point regarding /devices: I don't see this as duplicating /devices at all. /devices is set of control points -- you can open a file in /devices and control the associated device. The proposal is for a set of information points and is organizing a different set of information. -Peter Sumit Gupta wrote: > 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 > > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
