Re: Redesigning checkpoint_segments

On Wed, Jun 5, 2013 at 10:27 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> On 6/5/2013 10:07 PM, Daniel Farina wrote:
>>
>>
>> If I told you there were some of us who would prefer to attenuate the
>> rate that things get written rather than cancel or delay archiving for
>> a long period of time, would that explain the framing of the problem?
>
>
> I understand that based on what you said above.
>
>
>> Or, is it that you understand that's what I want, but find the notion
>> of such a operation hard to relate to?
>
>
> I think this is where I am at. To me, you don't attenuate the rate that
> things get written, you fix the problem in needing to do so. The problem is
> one of provisioning. Please note that I am not suggesting there aren't
> improvements to be made, there absolutely are. I just wonder if we are
> looking in the right place (outside of some obvious badness like the PANIC
> running out of disk space).

Okay, well, I don't see the fact that the block device is faster than
the archive command as a "problem," it's just an artifact of the
ratios of performance of stuff in the system. If one views archives
as a must-have, there's not much other choice than to attenuate.

An alternative is to buy a slower block device. That'd accomplish the
same effect, but it's a pretty bizarre and heavyhanded way to go about
it, and not easily adaptive to, say, if I made the archive command
faster (in my case, I well could, with some work).

So, I don't think it's all that unnatural to allow for the flexibility
of a neat attenuation technique, and it's pretty important too.
Methinks. Disagree?

Final thought: I can't really tell users to knock off what they're
doing on a large scale. It's better to not provide abrupt changes in
service (like crashing or turning off everything for extended periods
while the archive uploads). So, smoothness and predictability is
desirable.