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.ri...@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
