Bug#651280: don't allocate all available disk space in standard LVM partioning scheme
On Wed, 31 May 2023 at 16:38, Cyril Brulebois <kibi@debian.org> wrote:
>
> Control: severity -1 wishlist
>
> James Addison <jay@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)
Reply to: