[OpenAFS] Re: Swap RW and RO volumes ?
Thu, 17 Dec 2009 11:50:41 -0500 (EST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub1.dartmouth.edu id nBHGofKI015226
On Wed, 16 Dec 2009, Andrew Deason wrote:
>> On Wed, Dec 16, 2009 at 3:19 PM, Richard Brittain
>> <Richard.Brittain@dartmouth.edu> wrote:
>>> We have some large data volumes not backed up in any way other than
>>> a daily replicate to a different server. =A0The users normally access
>>> the volume via an explicit RW mount point.
> So, do you need them to actually be normal RO volumes? This sounds more
> like a use case for shadow volumes, but you need to be a little careful
> with those.
I initially looked at shadow volumes, but then I realized that all we wer=
doing fit completely within the functionality of traditional replicates.
We leave the RO mounted in a separate tree so that users can fix their ow=
oopses (in theory). I see how it would only make sense to try this with =
>>> My question is, if I want to drain a volume of all RW volumes so I
>>> can do kernel updates etc. without a user-visible outage, is there
>>> any way to effectively swap the RW and RO volumes.
>>> Something like:
>>> =A0Lock RW
>>> =A0Release to bring RO in sync
>>> =A0Make RW 'offline'
>>> =A0Promote RO to RW in the VLDB
>>> =A0Demote old RW to RO in the VLDB
> You can sorta do part of that with 'vos convertROtoRW', but it's not a
> VLDB-only operation; you gotta change disk metadata, too. Can't convert
> an RW back to an RO, though.
>> I could imagine a tool which took the volume offline, rewrote the
>> volume header, changed the VLDB entry to invert the IDs, and put it
>> back online. There's no such tool that I know of now.
> And I think there'd be problems if you tried to use such a thing with
> more than one RO.
>> However, once they're in sync, you might be able to vos clone the
>> readonly on the non-rw site to an rw, then update the vldb. i'd have
>> to read code/try it.
> I thought something about the way we COW made cloning a bit one-way. At
> the very least, the vol header would indicate the clone as a non-RW, I
Richard Brittain, Research Computing Group,
Kiewit Computing Services, 6224 Baker/Berry Library
Dartmouth College, Hanover NH 03755