Bug#907606: fsck takes hours to complete, just due to slow screen output

Thorsten Glaser t.glaser at tarent.de
Wed Jan 5 17:53:54 GMT 2022

tags 907606 - unreproducible

On Wed, 5 Jan 2022, Adam Borowski wrote:

> Yet in so many cases it's this log output that's an order or two of
> magnitude slower than actual fsck.  Even a spinner gives 200 seeks per

Indeed, especially with fb consoles it’s very very slow on scroll,
but slow serial links are obviously a similar PITA.

I’ve seen this, so removing the tag.

> I don't think there's much point running fsck on boot time on any filesystem
> newer than ext2 (ie, Hurd),

I do. If the journal replay suffices, it doesn’t do much, but if
not it’s needed.

> but if it's being done, there's no point dumping
> all these details to the screen where no human can possibly read.

Except for the case where fsck becomes interactive, or the last
thing is actually relevant…

> Perhaps we should decrease fsck's verbosity or rate-limit screen output,
> discarding excess text?

I’d suggest something like OpenBSD’s build watcher, that is,
'fsck >log 2>&1 & while sleep 2; do tail -3 log; done', or
the watch utility. But the fsck can suddenly become interactive
case is a problem.

Humans see “Clearing orphaned inode […]” so collapsing these
into a “Clearing orphaned inodes: $count\r” would be possible,
but some log should be guaranteed to have the full information
once booted (and, perhaps, even if the boot aborts).

I believe this would be best served by support from within
the relevant fsck utilities and perhaps starting by taking
e2fsck into Cc to discuss ideas is a good first step? Maybe
an extra option¹ that reduces screen output while adding
the full information to some file (which tbd because we need
to consider root fs fsck, then copying that over later to
whereever /var is, and with/without initrd setups).

① probably not an option, because all fscks would need to
  support this in lockstep, but perhaps an environment
  variable which can then be added to these that need it,
  i.e. these that can produce more than a couple of lines
  of output on boot (not all do)…

Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!

More information about the Debian-init-diversity mailing list