On Wed, 31 May 2023 at 16:38, Cyril Brulebois <k...@debian.org> wrote: > > Control: severity -1 wishlist > > James Addison <j...@jp-hosting.net> (2023-05-31): > > After the changes made to address bug #924301 (mountpoints for ext[n] > > filesystems that have insufficient free blocks are not automatically > > checked for faults), I think that this bug could be considered more > > serious. > > How do you figure?
Previously, after installation without enough free blocks, system administrators would be notified (perhaps repeatedly) about lack of space encountered by each e2scrub run. For installations after #924301 the administrator is less likely to be aware of the problem (the alarm was silenced, but the cause had not been addressed). In either case, recoverable filesystem errors could occur on the installed system -- the difference is that in the former case, the administrators are more likely to have been aware (and at an earlier point in time) about the risk. > > The disk space required for e2scrub[1] snapshots is 256MiB and the > > default allocation for LVM (encrypted or unecrypted) in the bookworm > > RC4 installer is 100% (same as originally reported here in Y2011). > > That's the default setting. Users who want to use e2scrub can tweak it. The volume group allocation size can be adjusted during an interactive install session, yep - the operator is prompted to input a size, and the default value is the full extent of the block device (my terminology may be a bit wonky). (the 256MiB requirement appears to static, though - it's a fixed size for exactly one snapshot, I suppose)
