[OpenAFS-devel] Re: open issues for an openafs 1.8 branch

[Benjamin Kaduk]

On Tue, 14 Oct 2014, Andrew Deason wrote:

> I agree with not shipping a .la, but was the question here to ship a .la
> vs a .pc, or just not ship anything?
>
> I thought we'd be providing a pkg-config .pc file for these, but I'm not
> sure if that's been brought up at all.

It has not been brought up.  I am not opposed to shipping a .pc file.

I think the question was "ship .la or not ship anything", but the question
can be easily changed.

> > > (4) changing fileserver tuning
> > >
> > > The fileserver lets you pass arguments like -S and -L for "small" and
> > > "large" setups.  But ... the "large" one is actually quite small, by
> > > today's standards.  We probably ought to update what those coarse-grain
> > > settings do, and the defaults as well.
> >
> > Good luck with getting agreement about small and large.  Perhaps these
> > should be more like the client (with respecting to its auto-tuning of
> > the cache size) and use some percentage of memory on the machine.
>
> Yes, these 'small' and 'large' distinctions are useless. I agree that
> having something autotune parameters based on memory (like the CM bases
> many decisions based on cache size) is the best way to go. Then it's not
> "large" vs "small", it's "16G of ram" vs "16M of ram". This should be
> intuitive, since almost all (or even all) of the options that just
> change numbers are memory/speed tradeoffs.
>
> I don't feel this needs to happen on a big version boundary (so it
> wouldn't block branching or 1.8 release etc), but that would be nice.
> Something like '-auto 16G' can be done fairly easily; you just need to
> pick values for different memory amounts. For something like '-auto 20%'
> I think you'd need to add some platform-specific code for memory
> probing, which is a little more work. If that is implemented, we can
> just have the default be something like '-auto 20%', and have all other
> parameters autotuned from that.
>
> I would very much prefer something like that to exist, rather than
> adding another "size class", or even just changing the defaults.

The main thing I want is to have a concise way of stating a config that is
reasonable for most modern hardware.  It would be great if that was no
arguments at all, but I think Jeffrey is sufficiently concerned that that
would break existing BosConfigs that that's off the table.  If we don't
get things in place for an -auto NNN to happen, I think a -X is still
preferable to the current state.

> > > Going through the output more carefully, I also found --disable-gtx,
> > > --disable-uss, --enable-bitmap-later, and --disable-unix-sockets,
> > > which I
> >
> > I don't see the reason for --disable-gtx.  --disable-uss
>
> I thought --disable-gtx was to avoid ncurses. I thought I saw somewhere
> that maybe this could just be --without-ncurses, and have basically the
> same result?

I think that's probably true, but may not actually do anything with it
myself.

> > bitmap-later (and fast-restart) are both just poor versions of DAFS.
> > They should be deprecated for 1.8 (accept the options and print a
> > warning that the user should switch to DAFS).
>
> These really are not necessarily replaceable by DAFS. They are
> effectively replaced by DAFS for everyone except for the people that
> complain that DAFS is still too slow for their purposes. I cannot speak
> for them (the research labs), but I thought they were still of that
> opinion and would appreciate these options not going away completely
> yet.
>
> fast-restart was already removed, and turned into a runtime option for
> the fileserver (-unsafe-nosalvage).
>
> bitmap-later could get the same treatment, and really seems a bit
> orthogonal to DAFS. If bitmap-later actually works and doesn't introduce
> serious issues (iirc this has been debated, but I haven't looked at it
> much so I can't say), it would be useful to have on all the time. It
> just delays loading/calculating the vnode bitmap until it's actually
> needed; it's even more lazy-evaluation (for one particular structure)
> than DAFS is.
>
> A quick glance suggests that bitmap-later is easy to turn into a runtime
> option; the #define doesn't change structure definitions or anything
> like that.

I think we can probably consider this "optional" for 1.8.  I'm not sure
whether I will put any time into it.

-Ben