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 <s...@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
like
if ( VolumeIsShadow && ! YouAreAnAdmin ) {
return GOAWAYYOUHOSER;
}
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 | k...@tproa.net | http://kula.tproa.net/
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
