On Mon, 20 Dec 2010 19:00:18 -0500 Steve Simmons <[email protected]> wrote:
> Coming to the more specific vlserver-vlserver-ubiq questions - yeah, > that's hard. If all we're thinking of is simple records that could > (please, god, please!) be shoehorned into the dbs, those are > relatively simple issues. I dunno if that's possible, tho. In > addition, it ignores any possible issues that may arise when the db is > in a transitional state - ie, an incomplete subset of the volume > family data has been distributed and somebody makes a query about it. > As far as I know, ubiq doesn't have any concept of atomic commits > across multiple entries. That makes processing volume families in any > except the simples ways very hard. vldb entries aren't mapped to any particular ubik structure; data in ubik is just a byte stream separated by pages that are modified by dbserver processes and committed atomically when the ubik transaction ends (successfully). You can modify multiple pages in a single ubik transaction (and we do; we just currently do not offer any vlserver RPCs that let you modify multiple vl _entries_ at once). So I don't see that being a significant problem. My point is just that the problem of compatibility with the existing vldb format is the most significant problem. All of the other issues to work out are by comparison rather easy. Once you get another value tied to the vl entry (AfsLockId is the only unused field; so afaict it's either that, or create another whole new entry called $volname.shadow or something), you can point it at an arbitrary space in the ubik db file with whatever structure you want, and old vlservers won't look at or interpret the new data. _Or_ maybe you use a different ubik database number for new vldb data. In theory older vlservers would accept and store that data without needing to know what's in it, but I don't think they actually handle it well. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
