[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule
Russ Allbery
rra@stanford.edu
Thu, 17 Jun 2010 10:43:07 -0700
"Christopher D. Clausen" <cclausen@acm.org> writes:
> Rainer Toebbicke <rtb@pclella.cern.ch> wrote:
>> No, of course not.
>> It would be painful to have to put back the '--enable-fast-restart and
>> --enable-bitmap-later' code if you removed them, probably dangerous. My
>> plea is to keep them in as an alternative to the demand-attach
>> file-server: with mandatory salvaging the non-demand-attach case is
>> seriously impaired, hence disabling it is no real alternative.
>> With the ambitious schedule for new releases I see this happening very
>> quickly. I'd like to avoid having to stop at a particular release next
>> year because of a functionality that we manage to live without, and
>> miss others that we're interested in.
> I agree with Rainer on this.
Chris, to check, are you currently using --enable-fast-restart or
--enable-bitmap-later?
Please understand that neither of those options are recommended now,
whether you have DAFS enabled or not. I consider --enable-fast-restart in
particular to be dangerous and likely to cause or propagate file
corruption and would not feel comfortable ever running it in production.
I know that some people are using the existing implementation and taking
their chances, and if they're expert AFS administrators and know what
they're risking, that's fine, but, as I understand it, it's pretty much
equivalent to disabling fsck and journaling on your file systems after
crashes and just trusting that there won't be any damage or that, if there
is, you'll fsck when you notice it.
> At the same time, I'd be happy to start doing more testing of the
> various DAFS features, although I'm not quite sure what version I should
> be using for testing,
If you want to test DAFS, you need to use a 1.5 series server or (coming
soon) a 1.6 release candidate.
> nor am I completely sure how to actually migrate an existing file server
> to use DAFS or if there is a reverse path to downgrade if I encounter
> problems.
Migration is documented in the bos_create(8) man page as one of the
examples. You can do the inverse procedure to downgrade, although of
course you'll also need to replace the server binaries with a version
compiled without demand-attach.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>