Hi Simon, On Jun 17, 2010, at 21:01 , Simon Wilkinson wrote:
>
> On 17 Jun 2010, at 19:45, Christopher D. Clausen wrote:
>> Its fine to not have it enabled by default, but I can't see why one would
>> remove the functionality from the source tree.
>
> Because every different configuration option you have doubles the complexity
> of testing the code. What actually tends to happen is that stuff that isn't
> enabled by default never actually gets tested when changes are made, and so
> ends up rotting.
hmm, that would apply to DAFS unless it's enabled by default starting with the
1.6 RCs?
> So, these options are dangerous both because we _know_ they can cause data
> loss now and that's only going to get worse in the future because nobody
> developing for the fileserver actually tests with them enabled.
Some not so small sites (including mine) seem to be using them - and actually
don't test anything else right now.. We've been using these options ever since
I started caring for AFS fileservers a couple of years ago. We've been bitten
(just search the list for my cry for help and Jeff's answer pointing me to
vol-bless), but I'm not sure by what. It possibly was fast-restart, but there's
no proof. This case was a severe failure of the underlying (crappy) storage,
and all data on such a device is at His mercy anyway... Digging through /vicepx
back then revealed that all the data (and metadata) was actually completely
intact, except for files being written at the time of the crash. The only
actual problem was the blessed=0 in the volume header - and the salvager wasn't
able to fix it.
> We have very limited developer effort available. Reducing the breadth of our
> code significantly improves our ability to add the new features that everyone
> says they want.
That's completely reasonable. But it clearly means that DAFS should the one and
only option to run fileservers with 1.6+. Is this what's planned? Fine, let's
test it (and nothing else) and get it ready. But if DAFS remains an option that
has to be enabled explicitly at build time, I'm with Rainer and Christopher:
please leave fast-restart and bitmap-later in place.
> My original proposal for both fast-restart and bitmap-later was that we
> should remove the configuration options but retain the code for one release
> cycle and then remove the code entirely in the next cycle. That hopefully
> prevents folk from running them thinking that they're in any way supported,
> but still allows those brave enough to do so some time to move over to demand
> attach.
Unless it's too hard to get them back without the configure options: ok.
Cheers,
Stephan
--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
smime.p7s
Description: S/MIME cryptographic signature
