On Thu, Oct 25, 2018 at 8:44 PM diego righi <[email protected]> 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
