Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 4, 2021 8:21 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on March 4, 2021 1:44 pm wrote:
> >
> > I have not noticed any delay on my workstation which has 64G.
>
> The people who were hurting are the people with many hundreds of gigs (or terabytes)
> of RAM, and have five-nines availability guarantees, and want their scheduled
> maintenance reboots to take on the order of seconds, not minutes.
>
> Yes, yes, they obviously actually use many other strategies (ie multiple nodes with fail-over etc) because
> generally there's no way they'll hit the reboot speed requirements even for scheduled downtime, much less
> for when something actually goes wrong. But they do tend to want "fail fast, and get back up fast".
>
> People like that absolutely hated the traditional SCSI disk spin-up times, and they found fsck times
> completely unacceptable, and they want the RAM to be scrubbed and initialized incrementally so that you
> can boot and get the system up and the loads started ASAP. Keep scrubbing and initializing more RAM in
> parallel, because it's going to take a while before you're under full load and need it all anyway.
>
> Those people tend to be a fairly special breed.
>
> There's very much the other kind of server person, who is used to (and so resigned as to expect) the server
> reboot taking possibly tens of minutes, because that's just what they always did - spinning up one rotating
> platter of rust at a time to avoid the power surge of spinning them all up at the same time etc etc.
>
> I'm not even kidding. That whole "spin up one disk at a time" is
> not some exaggeration. It was standard practice in many places.
>
> Of course, it's largely historical, and had real roots - those disks used to be massive, and spinning
> them up really was a big deal. It's just that the practice of spinning disks up one at a time actually
> went on in many places long after those physically massive disk systems were long long gone.
>
> So you have this odd dichotomy of boot speed expectations in the big iron world. Some want it
> to be really instant and quick. And some are perfectly happy with ridiculously slow boots.
>
> I've had access to big powerful hardware that was almost entirely useless for kernel development, because
> while they could compile a new kernel really quickly, they then took literally several minutes to boot
> the damn thing. So a much slower machine was actually much better at doing any actual testing on.
>
Yeah, I had the same issue with a HP-UX machine (HP-747i) in the 90s for developing for a 68030 based VME communication card. Compiling and linking the kernel driver took seconds, rebooting without fsck took 15 minutes, with fsck 25 and it was really easy to crash the machine when communicating over the VME bus. What a luck that I could do most of the 030 part of the code on my Atari TT, otherwise I would probably not have survived that project.