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

Thomas Kula kula@tproa.net
Mon, 20 Dec 2010 19:10:10 -0500

On Mon, Dec 20, 2010 at 07:00:18PM -0500, Steve Simmons wrote:
> On Dec 20, 2010, at 3:29 PM, Andrew Deason wrote:
> > 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.
> Yes, 'read-only' is sloppy terminology on my part. 'Enforcement' of the read-only nature was done by virtue of the shadow being invisible to most things that access volumes.

Actually, If I'm remembering correctly, down in the bit of fileserver
code that determined access to a particular object we put in something

 if ( VolumeIsShadow && ! YouAreAnAdmin ) {

Just wrapped up more fancy. This was in the Michigan code,
not something we pulled in from what was in openafs.org code,
again if my memory is serving me well.

Thomas L. Kula | kula@tproa.net | http://kula.tproa.net/