The most recent merge of the aix-support branch into master includes the changes necessary to make this a reality. I've also updated efs-core-docs to reflect this as well.
There are likely a number of documentation changes still to make, and we'll update them as we find them. I'll be building out my new EFS 3 environments (test and prod) without instances, so I should flush out anything not covered by the test suite in the due course of deploying things. Full steam ahead.... On Wed, Aug 24, 2011 at 4:29 PM, Phillip Moore <[email protected]>wrote: > I'm working on support for an AIX client for EFS, and this has raised an > interesting challenge. This is preliminary, since I'm still learning about > AIX and the various hardware platforms it runs on, but one thing is > immediately clear: the platform values are easy, but the instances are > difficult and largely useless. > > For x86-32 and x86-64, we were able to create instances for > amd32/amd64/ia32/ia64, and for Sparc chips, Sun already breaks them down > into sun4u, sun4m, sun4v, etc. I have not found a similar breakdown for > the powerpc chips IBM sells, and the problem is that the breakdown is an > order of magnitude more complex than the breakdown for Intel and Sparc > chips. > > Now, consider that fact that NOT ONCE did we ever find a use case that > required us to create instance-specific installs. The motivation behind > supporting them in the first place was that in the past such edge conditions > DID exist, and there was value in providing binaries for amd vs ia, or sun4v > vs sun4u, etc. > > I am seriously thinking of a major enhancement to OpenEFS: make the use of > instances entirely optional. If we only define platforms, and those > platforms have no instances defined, then the code should be able to Just > Work. This will also significantly reduce the complexity of the .exec > directories, and the extra layer of indirection used for the exec magic. > > I have been reviewing the code to see how hard this would be, and while > it's not trivial by any means, I think it's very doable. I am also > considering NOT using instances AT ALL in the initial deployment of EFS I'll > be using in my new role. It will be possible to define them after the > fact, and extend the existing namespace ("efs execlinks any" does this > already -- gets the filesystems in sync with the database platform > definitions, globally), so it's not a decision you have to live with. > > Here's my thoughts on how this changes the code: > > [-] efs_platform > > This script will have some embedded knowledge about the platforms and > instances, by necessity. For AIX, I am going to have the output of > "efs_platform --instance" simply return the platform name. > > [-] efsclient (the boot script, formerly rc.efs) > > This script will try to mount the instance-specific subdirectories for > /.efs/dist and /.efs/dev, and if that fails, will fall back to mounting the > platform-specific subdirectories. This means that NO client-side > configuration is necessary. If the EFS domain has not defined instances > for that platform, then the instance-specific subdirs simply won't exist. > > [-] efs execlinks any > > Actually, this covers ALL of the code that manages the .exec directory and > the rest of that indirection. Some of the code will Just Work, as is, > since it loops over a list of instances to do most of what it does, and that > list might just be empty. The biggest change is that in addition to create > instance specific subdirs (/vol/efs_dist/efs_qtree/$instance/dist) the code > will ALSO have to create platform-specific subdirs as well. > > [-] test suite > > This is actually the hard part. We really want to test how things behave > with and without the instances defined, but it has to be done. > > Now, why do I think this is worth doing? First of all, AIX sort of forces > the issue, since there's no obvious way to define the instances in a > meaningful way. More importantly, this will mean that platform-only > environments (and it would make sense to make the EFS 3 deployment at BAC > use platforms only, too) will be far less confusing for users who make the > mistake of actually looking at the .exec directory. >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
