On Sat, Sep 25, 2010 at 11:24 AM, Phillip Moore <[email protected]> wrote: > > I'm splitting up the topics here, just to avoid writing a novel in one > email.... > Volume names: the more I think about this, the more I think they should be > managed per-domain (EFS domain, that is). One thing EFS *must* assert for > a single EFS domain that manages multiple cells, is consistency in the > directory structure, in the namespace that is /efs. This is core > functionality for EFS. > I think that if you make the volume names per-AFS cell, it will just > complicate the code, and make debugging and diagnosing problems with the > namespace more difficult. It will also complicate the code and the database > significantly. > One facet of the EFS design I am not willing to change is the conceptual > idea that an EFS domain is a single, high level administrative domain. EFS > is all about bring global consistency to a large enterprise, and I think > this is an example of enforcing that consistency. I am NEVER going to > support per-cell, per-region, etc. releasealiases, for example (I predict > an annual argument with the user community over this one). > Having said that, I'll certainly listen to counter arguments for allowing > the volume names to be cell-specific, but I personally think they should be > global. > Ah. I was interpreting per domain vs per cell as a different argument. I completely agree that a given volume name that is 'in' EFS should be consistent across all cells in the domain.
There needs to be some thought, though, to how migration of an existing infrastructure would occur. One could, for example, simply build out new cells for EFS, but it's worth thinking through how we might introduce EFS into an existing AFS cell. That would probably argue for certain volumes (e.g., root.afs, root.cell) being managed specially for a given cell, and then certain mountpoints existing under that for the 'legacy' and 'EFS' namespaces. But as you say elsewhere, we can speculate forever on how integration might happen. Better is talking with people who are considering using it and seeing what their needs actually are. Steven _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
