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 _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
