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.
The only possible way to make instances useful in this case is to use the
SAME cpu identifier, and simply add more granularity to the osrel. For
example, if the platforms for AIX 6.* on PPC were:
ppc32.aix.6
ppc64.aix.6
Then we could define instances that add the minor OS release:
ppc32.aix.6.1
ppc64.aix.6.1
ppc32.aix.6.2
ppc64.aix.6.2
etc.
However, I still don't see a real world use case that would require this,
and you can always ADD definitions and extend the namespace later, when you
discover that you need them.
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. Again, 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 forever.
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.
Thoughts?
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
