Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On Thu, Jun 17, 2010 at 1:43 PM, Russ Allbery wrote: > "Christopher D. Clausen" writes: >> Rainer Toebbicke 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 >>>

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Tom Keiser writes: > Ok. That's a perfectly fair rationale. What I still don't understand > is why people think _OpenAFS_ should strive to ship (and thus implicitly > endorse) code that introduces such non-determinism (especially given > that, as Andrew pointed out, under DAFS enabling fast-res

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Rainer, I don't mean to pick on you, but I see this probabilistic argument all too frequently; I think it requires response. I'll readily concede that over the short-term while we are triaging bugs that a probabilistic argument, such as the one you make below, is perfectly reasonable. After all,

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

"Christopher D. Clausen" writes: > Russ Allbery wrote: >> The code is dire verging on unsupportable and really needs to be >> rewritten. > If the code is so bad, why was it accepted in the first place? Because we didn't have the code review mechanism that we have now, the coding standards that

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery wrote: "Chas Williams (CONTRACTOR)" writes: Russ Allbery writes: I definitely agree that this is where we should go. I don't think we're quite ready to be there right now, unless you feel that we should enable supergroups by default. :) (I can't reasonably turn it off in the D

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

"Chas Williams (CONTRACTOR)" writes: > Russ Allbery writes: >> I definitely agree that this is where we should go. I don't think >> we're quite ready to be there right now, unless you feel that we should >> enable supergroups by default. :) (I can't reasonably turn it off in >> the Debian pack

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

In message <4c1b40ad.1040...@pclella.cern.ch>,Rainer Toebbicke writes: >I beg to disagree: the Volume/Vnode back-end has by no means the same problems >that a file system might have. Damages there will never wildly destroy random >items on disk, as you would have to be afraid using in a file syst

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

In message <8739wluuw3@windlord.stanford.edu>,Russ Allbery writes: >I definitely agree that this is where we should go. I don't think we're >quite ready to be there right now, unless you feel that we should enable >supergroups by default. :) (I can't reasonably turn it off in the Debian >pac

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Jeffrey Hutzelman schrieb: Really, I consider enable-fast-restart to be extremely dangerous. It should have gone away long ago. I realize some people believe that speed is more important than not losing data, but I don't agree, and I don't think it's an appropriate position for a filesystem

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

> I'd really like us to standardise on a _small_ (ideally one) set of > supported configurations which we suggest for each release - and for > the binary packages that we point users at to use that set of > configurations across all platforms. It's the only way that we're > ever going to manage to

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

--On Thursday, June 17, 2010 11:38:18 PM +0100 Simon Wilkinson wrote: On 17 Jun 2010, at 21:40, Russ Allbery wrote: There is that. I intend to ship with DAFS enabled for Debian, but the Debian packages have always taken a fairly aggressive approach to enabling features. (They have had sup

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

--On Thursday, June 17, 2010 01:45:14 PM -0500 "Christopher D. Clausen" wrote: I have heard that, but I have never experienced any problems myself in many years of running that way. In general the way I see it is that if the power goes out, my server stays up for a little longer due to its UP

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

--On Thursday, June 17, 2010 11:59:29 AM -0700 Russ Allbery wrote: I'm quite sure that, after an unclean crash, your Windows server doesn't remount the file system without doing a consistency check. No operating system treats its file systems that way. MS-DOS did. Of course, that hardly qu

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Simon Wilkinson writes: > On 17 Jun 2010, at 21:40, Russ Allbery wrote: >> There is that. I intend to ship with DAFS enabled for Debian, but the >> Debian packages have always taken a fairly aggressive approach to >> enabling features. (They have had supergroups enabled for quite some >> time,

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On 17 Jun 2010, at 21:40, Russ Allbery wrote: > > There is that. I intend to ship with DAFS enabled for Debian, but the > Debian packages have always taken a fairly aggressive approach to enabling > features. (They have had supergroups enabled for quite some time, for > example, and also enable

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Simon Wilkinson writes: > On 17 Jun 2010, at 21:29, Russ Allbery wrote: >> Steven Jenkins writes: >>> I thought that enabling DAFS to be on by default was the major feature >>> of 1.6. >> Shipping DAFS and declaring it supported is the major feature of 1.6. >> Making it the default is another q

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On 17 Jun 2010, at 21:29, Russ Allbery wrote: > Steven Jenkins writes: > >> I thought that enabling DAFS to be on by default was the major feature >> of 1.6. > > Shipping DAFS and declaring it supported is the major feature of 1.6. > Making it the default is another question entirely. The dif

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Steven Jenkins writes: > I thought that enabling DAFS to be on by default was the major feature > of 1.6. Shipping DAFS and declaring it supported is the major feature of 1.6. Making it the default is another question entirely. -- Russ Allbery (r...@stanford.edu)

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On Thu, Jun 17, 2010 at 4:13 PM, Russ Allbery wrote: > Stephan Wiesand writes: >> On Jun 17, 2010, at 21:44 , Russ Allbery wrote: > >>> Yes, absolutely.  It's one of the reasons why 1.6 has taken so long. >>> There probably isn't any other sane way to drop in a major, disruptive >>> change, but c

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Stephan Wiesand writes: > On Jun 17, 2010, at 21:44 , Russ Allbery wrote: >> Yes, absolutely. It's one of the reasons why 1.6 has taken so long. >> There probably isn't any other sane way to drop in a major, disruptive >> change, but certainly the long-term goal is to ensure DAFS works in >> pro

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Hi Russ, On Jun 17, 2010, at 21:44 , Russ Allbery wrote: > Stephan Wiesand writes: >> On Jun 17, 2010, at 21:01 , Simon Wilkinson wrote: > >>> Because every different configuration option you have doubles the >>> complexity of testing the code. What actually tends to happen is that >>> stuff th

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Stephan Wiesand writes: > On Jun 17, 2010, at 21:01 , Simon Wilkinson wrote: >> 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 >> chan

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

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 opti

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

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 c

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

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 te

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

"Christopher D. Clausen" writes: > Russ Allbery wrote: >> Chris, to check, are you currently using --enable-fast-restart or >> --enable-bitmap-later? > Yes, both of them. Aie. > I have heard that, but I have never experienced any problems myself in > many years of running that way. Yes, that

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery wrote: Chris, to check, are you currently using --enable-fast-restart or --enable-bitmap-later? Yes, both of them. 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 dan

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Andrew Deason writes: > I haven't used uss and so don't know how useful it is to keep in the > OpenAFS tree, but perhaps something like it should be spun off into > another project; I'd imagine it's one of those things that many > organizations write themselves at some point or another. a...@uiuc

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

"Christopher D. Clausen" writes: > Rainer Toebbicke 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

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Rainer Toebbicke wrote: Derrick Brashear schrieb: Considering it a showstopper when you admit one graph earlier that you're already running with a patched tree seems a bit overblown, perhaps? The tree is now gold and patches may no longer be applied? No, of course not. It would be painful to

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On Wed, 16 Jun 2010 20:46:25 -0400 Jason Edgecombe wrote: > We're using uss in a non-kaserver environment. I know that we could do > without it, but it's nice to have. If uss weren't available, an > equivalent tool would need to be available. I haven't used uss and so don't know how useful it is

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Derrick Brashear schrieb: Considering it a showstopper when you admit one graph earlier that you're already running with a patched tree seems a bit overblown, perhaps? The tree is now gold and patches may no longer be applied? No, of course not. It would be painful to have to put back the

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Considering it a showstopper when you admit one graph earlier that you're already running with a patched tree seems a bit overblown, perhaps? The tree is now gold and patches may no longer be applied? Derrick On Jun 17, 2010, at 3:30 AM, Rainer Toebbicke wrote: Russ Allbery schrieb:

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery schrieb: I'm aware of the following (largish) things that we want to deprecate or remove: * --enable-fast-restart and --enable-bitmap-later are earlier attempts to solve the problem that is solved in a more complete way by demand attach. Demand attach will be available in 1.6

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On Jun 16, 2010, at 22:29 , Jeffrey Altman wrote: On 6/16/2010 9:50 PM, Russ Allbery wrote: Jason Edgecombe writes: We're using uss in a non-kaserver environment. I know that we could do without it, but it's nice to have. If uss weren't available, an equivalent tool would need to be availabl

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On 6/16/2010 9:50 PM, Russ Allbery wrote: > Jason Edgecombe writes: > >> We're using uss in a non-kaserver environment. I know that we could do >> without it, but it's nice to have. If uss weren't available, an >> equivalent tool would need to be available. > > Hm, that implies that it's current

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Jason Edgecombe writes: > We're using uss in a non-kaserver environment. I know that we could do > without it, but it's nice to have. If uss weren't available, an > equivalent tool would need to be available. Hm, that implies that it's currently useful now. Should we just provide a way to disab

Re: [OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On 06/15/2010 09:47 PM, Russ Allbery wrote: * As we've stated for some time, at the point at which we release an OpenAFS 2.0 with rxgk, we intend to deprecate kaserver. What I believe that should mean is that, in OpenAFS 2.0, we will require passing a flag to configure to build kaserve

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

On Wed, Jun 16, 2010 at 6:07 AM, Hartmut Reuter wrote: ... >> > > Without --enable-fast-restart after a fileserver crash the salvager used to > salvage all volumes in all partitions before the start of the fileserver. > On large fileservers this could take hours and sometimes the salvager went out

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery schrieb: > I'm aware of the following (largish) things that we want to deprecate or > remove: > > * --enable-fast-restart and --enable-bitmap-later are earlier attempts to > solve the problem that is solved in a more complete way by demand > attach. Demand attach will be availabl

[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

Russ Allbery writes: > After 1.6, we currently have the following plan. This is definitely > open for discussion and is not set in stone, but it's our current > intention. Please send feedback (preferrably to openafs-devel, since I > believe that's where most of the discussion will be). As was