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

[Andrew Deason]

On Mon, 20 Dec 2010 14:46:38 -0500
Steve Simmons <scs@umich.edu> wrote:

> A shadow volume is a read-only remote clone of a primary volume. We
> had to create some terminology here, and 'primary' is what we called
> the real-time, in-use, r/w production volume. A remote clone closely
> resembles a read-only replica of a volume, but differs in several
> important respects.

By 'read-only' do you just mean in intended usage? I may be way off, but
my memory of shadow volumes (as implemented in openafs.org code) is that
they are are virtually identical to the primary, and are not marked as
RO volumes or anything like that in the underlying namei metadata. So, a
fileserver could theoretically attach it and modify it, though it was
intended that the lack of an entry in the vldb would prevent clients
from accessing it.

> First and foremost, it does not appear in the vldb. Thus there is no
> possibility of the read-only copy coming into production.

I understand this was probably the best way to do this at the time, but
this alone does not prevent the volume from getting used. Since vldb
results are cached by clients and an administrator could screw up vldb
data somehow, it's possible for someone to access the wrong volume.

> Shadow volumes could be detected only on the server on which they
> reside. Modification were made to vos listvol for that purpose. A bit
> in the volume header was selected for distinguishing a shadow from a
> primary volume; I believe that was the only modification made to the
> volume header file. This work is also done.

By "done" does this mean you just implemented it at umich, or it's in
the openafs.org tree? Is the volume header bit you're referring to
inService (or another existing flag), or did you use a separate field
specifically for shadows?

> I think we were sliding towards a transparent upward-compatible
> replacement of the vldb as well. Based purely on how I imagine the
> vldb to work :-), it should be possible to add shadow data to it and
> define some additional rpcs. Users of the old rpcs would only get the
> data that was in the 'legacy' vldb, users of the new rpcs would get
> shadow data as well. That's a door folks may not want opened yet, but
> it seems a better choice than bolting a separate shadow-oriented vldb
> to the side.

I thought the bigger problem is not the compatibility of the
client<->vlserver interface, but rather the vlserver<->vlserver
interface; that is, the structure of the VL entries in ubik, since those
structures doesn't have any spare fields (although LockAfsId is not
used). You can probably play some games to keep enough compatibility
with older vlservers, but it requires some thought.

-- 
Andrew Deason
adeason@sinenomine.net