crash dump progress should be emitted more frequently
If the system panics, a crash dump is (hopefully) written to disk. Systems with a large quantity of DRAM can take a considerable period of time to dump to disk, during which the operator may not interact with the machine to determine its status.
If the system is configured to use the VGA console, when the operator views that console via a monitor or some remote KVM facility, the fact that the system is writing a crash dump is easy to see. A progress update is drawn to the screen each time one percent of progress is made toward completion.
For systems with a large quantity of memory, it can take many seconds or even minutes to write even one percent of the dump: one percent of 200GB is 2GB, and polled I/O is not especially fast. The operator would be forgiven for thinking that the passage of a minute or two without a progress update could signal that the system has hung while trying to dump.
Ironically, the use of the generally superior IPMI SOL support in the BMC to attach to the serial console of the machine actually further obscures dump activity. The operator can generally only see text emitted after attaching; infrequent updates mean that the operator may see nothing for minutes.
In order to alleviate these issues, we should take a two-pronged approach:
- liveliness will be signalled to the operator by drawing the progress display not just when the completion percentage changes, but also if a whole second has passed without an update
- operators with the good fortune to be able to use the serial console (and the impeccable taste to choose to do so) will know that the system is dumping because we will prepend
dumping:to each redraw of the progress report
Updated by Electric Monk over 4 years ago
- Status changed from New to Closed
commit 2fb0949cb8f76f6cc30b9fef03f032f1893bbc6c Author: Joshua M. Clulow <firstname.lastname@example.org> Date: 2016-06-09T22:32:41.000Z 7058 crash dump progress should be emitted more frequently Reviewed by: Robert Mustacchi <email@example.com> Reviewed by: Patrick Mooney <firstname.lastname@example.org> Reviewed by: Simon Klinkert <email@example.com> Reviewed by: Josef 'Jeff' Sipek <firstname.lastname@example.org> Reviewed by: Yuri Pankov <email@example.com> Approved by: Richard Lowe <firstname.lastname@example.org>