[OpenAFS] Re: State of the Michigan shadow system (long)

[Andrew Deason]

On Mon, 20 Dec 2010 19:00:18 -0500
Steve Simmons <scs@umich.edu> 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
adeason@sinenomine.net