[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#510544: Installer/partition guide tried to use 500GB as swap

Frans Pop <elendil@planet.nl> writes:

> On Thursday 08 January 2009, Ferenc Wagner wrote:
>> Looks like it's a problem with conversion to logical extents.
>> After running the recipe, perform_recipe_by_lvm settles on
>> 3246000 0 3246000 linux-swap ...
>> that is, on a 3GB swap, which is correct (300% of the 1GB RAM).
>> However, it issues
>> lv_create noc2 swap_1 1406
>> to create it, thus creating a 1406 extent big (5.6GB) LV.  This is to
>> use up all the remaining extents.  So the main LV got a little bit too
>> small...  Roundoff, maybe?  TBC.
> Could also be an overflow maybe.

The original report (concerning the 1.5 TB disk) hits an internal
limit which is in place to avoid overflow.  Recipes in general use MB
units, and then 1000000000 (1000 TB) is a big enough maximum for the
"unlimited" partition.  But partman-auto-lvm users kB units instead,
and then the supposedly unlimited maximum size drops to 1 TB,
effectively capping the size of the root LV, and all the rest gets
used as swap, because the code avoids leaving unused physical extents
in the VG.  To quote perform_recipe_by_lvm:

# expand_scheme can't cope with decimal and lvm overhead.
# lvm overhead gets calculated properly only using kbytes.
# Switch to that. The worst scenario is that the last partition will be one PE smaller,
# but in the big numbers it's nothing (4MB).
free_size=$(vgs -o vg_free --units k --noheading --nosuffix $VG_name | sed -e 's/\
foreach_partition '
        if [ "$3" != "1000000000" ]; then
        shift; shift; shift
        newscheme="$newscheme${NL}$newmin $newmed $newmax $*"

This should not affect my toy example with the 100 GB disk, but having
a 6 GB swap isn't that laughable as having 500 GB of it.

> Can you find the code that calculates the partition sizes and the extends 
> and reproduce the problem with a 'set -x' added, either in the specific 
> relevant script(s) or in /lib/partman/lib/base.sh?
> The last will give a huge amount of debug output, but has the advantage 
> that you can be sure to have it all. If you know what to search for it's 
> workable.

I'm not familiar with this code, but it isn't too hard to follow.  I
resorted to inserting logger commands here and there, that's easier to
digest than a full set -x log.  Fortunately it's also fairly easy to
reiterate the process.

So.  I don't fully understand the above comments.  What is decimal
overhead, for example?  The easiest way forward would be to stay with
MB units, but for that we should understand what's the problem with
the LVM overhead calculation in that case.  I haven't yet found that
in the code, but will continue with it (unfortunately my time is
rather fragmented).

Reply to: