On Thursday, October 25, 2018 9:59:09 PM -03 Philip Guenther wrote:
> On Thu, Oct 25, 2018 at 8:44 PM diego righi <diego.righi@gmail.com> wrote:
> > So why openbsd 6.4 i386 and amd64 bootloaders (not biosboot, boot!)
> > express different behavior? Wasn't openbsd about correctness? :/
>
> If I'm wrong and it is documented that I can't do this fine, but so also
>
> > i386 should not work, this behavior is just strange for me, that's it.
>
> This is something that most people, perhaps even most software developers,
> are not strongly aware of: that resource requirements are often both
> fine-grained and sharp-edged. That is: the exact requirements can vary in
> many fine-steps between systems, but there can be a sharp edge at which
> performance plummets badly or the system totally fails. This is true of
> *many* systems (including lots of cloud services) which work just fine
> until they *suddenly* fail, because the memory straw broke the available
> RAM camel's back, or the micro-service is now taking just _longer_ to
> service one request than the inter-request arrival interval so the queue so
> the queue grows in latency past the user/system tolerance.
>
> Case in point: the memory resources required by the biosboot code depend
> many factors including:
> * the size of the root partition
> * the block size of the root partition (which is affected by the size)
> * the inode number of the kernel being booted
> * the exact disk block numbers which the booted kernel was put in
>
> We all, the developers and the community of user who actively test -current
> kernel (THANK YOU!) exercise various combinations of those, the *vast*
> majority of which use the recommended system layout. That recommend layout
> doesn't push the first two of those items at all, and keeps the third and
> fourth in sane ranges.
>
> Meanwhile, those using monster root partitions have unknowingly been
> pushing the memory usage by biosboot, but below its limits.
>
> So, some change was made during the 6.3->6.4 dev cycle which requires
> _slightly_ more memory in biosboot. Maybe it was something about the
> compiler upgrades, or the maybe it was the SoftRaid crypto passphrase-retry
> change. Or maybe it was the tiny tweak of making biosboot default the
> console to com0 @ 115200 on VMs. Something made biosboot take more
> memory...and now those systems with monster root partitions were pushed
> over the edge of how much memory biosboot has available.
>
> Rule of thumb: the costs must be worth the gain.
> So:
> * enhancements and fixes break systems that don't get actively tested
> * we are are not going to block enhancements/fixes because of that
> * we test what we recommend, on many systems
> * if a change breaks the recommended config, then it'll get reverted/fixed
> * ...this is more likely the more quickly the problem is reported
> * ...and even then the recommendation for the future might change
> * we also test some systems that go beyond those recommendations...
> * ...but not all
> * if a system that doesn't follow the recommendations breaks as the result
> of a change, the developers will make a judgement about whether the gain of
> the change is worth the costs. We don't like breaking any config, even
> unusual ones, but if we think the setup is inadvisable, we'll say so and
> move on.
>
> In this particular case:
> * the changes to biosboot where in snapshots for MONTHS, but no one
> reported problems
> * if you aren't following recommendations, and aren't testing snapshots,
> then you should be 100% willing to change your configuration on upgrade,
> 'cause you ain't giving the feedback necessary to keep your unusual config
> alive
> * SINGLE PARTITION CONFIGS ARE DUMB, DON'T DO THAT; DON'T BOTHER
> COMPLAINING, JUST FIX THEM.
>
>
> Philip Guenther
Wow, that was enlightening!
I seldom learnt as much off a single post than with this one.
Thank you, thank you! Philip Guenther
Cheers
Eike
No comments:
Post a Comment