Bug#907606: fsck takes hours to complete, just due to slow screen output
On Wed, 5 Jan 2022, Loorey wrote: > information they can always by logs anyway. It’s not that easy. fsck can become interactive, and then there’s the point of where to write the logs during root and /var⚠ fsck and how to promote them to the eventual /var and this needs coordination between multiple packages I think anyway… bye, //mirabilos -- 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!
Bug#907606: fsck takes hours to complete, just due to slow screen output
tags 907606 - unreproducible thanks 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)… bye, //mirabilos -- 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!
Bug#907606: fsck takes hours to complete, just due to slow screen output
On Wed, Jan 05, 2022 at 03:17:50PM +, Loorey wrote: > FSCK is the utility for checking the filesystem for Errors and > fixing those, of course after an ungraceful shutdown this operation > can take hours, and of course printing the log will be much faster > than the actual operation, because fsck fixes the system while also > logging, and in the other case you are just reading and printing the > log file. 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 second, while a good modern disk can do in excess of 2M random reads. Meanwhile, a 115200 terminal is limited to 180 80-character lines per second, and fbdev on a high-end GPU is much slower than that. Cf #991218 which is this same problem from another program. I don't think there's much point running fsck on boot time on any filesystem newer than ext2 (ie, Hurd), but if it's being done, there's no point dumping all these details to the screen where no human can possibly read. Perhaps we should decrease fsck's verbosity or rate-limit screen output, discarding excess text? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.
Bug#907606: fsck takes hours to complete, just due to slow screen output
severity 907606 minor tags 907606 unreproducible quit Hey there! FSCK is the utility for checking the filesystem for Errors and fixing those, of course after an ungraceful shutdown this operation can take hours, and of course printing the log will be much faster than the actual operation, because fsck fixes the system while also logging, and in the other case you are just reading and printing the log file. Loorey Public Key Fingerprint: CDFB 530E 248B F5E7 915B EA35 CA0D 819B 719A 4DBD
Bug#907606: fsck takes hours to complete, just due to slow screen output
Package: initscripts Version: 2.88dsf-59.9 In case of an unclean shutdown or system crash fsck run at boot time can take several hours to complete, printing thousands of useless messages like Clearing orphaned inode 123456789 (uid=1000, gid=1000, mode=0100700, size=28) It depends of the speed of your console, of course, but using a terminal it is pretty unlikely that you get anything faster than 115200 bits/sec. Some VGA consoles are not noticeable faster than this, either. I had the chance to verify this problem on a master-backup system: - On the master the fsck is running for >16 hours and is not completed yet. It writes to a terminal with 9600 bits/sec. - On the backup (manually migrated to become the new master) the file system check of the same partition took about 30 minutes, using "fsck -y >& fsck.log". It wrote 54 MByte logfile. This could be improved. Init is sysvinit-core. Thanx in advance Harri
