On Saturday, July 01, 2006 06:25:19 PM -0700 Adam Megacz <[EMAIL PROTECTED]> wrote:
Other than the 7-volume-per-group limit, these seem like incredibly useful primitives. Is that limit (and other similar assumptions about volid numbering) engraved in the wire protocol, or is it specific to the OpenAFS codebase?
Primitives is exactly what they are -- they're building blocks intended to be used in the eventual construction of more complex functionality. They do not themselves constitute complete features, and the main issue is that you're likely to shoot yourself in the foot if you don't understand and accept that, or if you don't understand well enough what you're trying to accomplish and whether or how these primitives are useful for that.
The 7-volume-per-group limit is an artifact of the namei fileserver backend implementation. However, RW, RO, and BK volumes and the VLDB data corresponding to these volumes has specific semantics, and you may run into trouble if you do something nonstandard and then let it be seen by tools that don't understand what you've done. This is particularly the case if you put something wierd in the VLDB, or let your additional clones be seen by tools that update the VLDB.
Other than that, yes, you can use clone to make extra COW clones of things, and shadow them to another fileserver, and then bring the new server "live" if something happens to the first one. I added "vos shadow" for the purpose of building a system along the latter lines, though the rest of the work never happened. How to safely manage the "shadow" fileserver and bring it live when needed is left as an exercise for the reader.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
