Bug#510544: Installer/partition guide tried to use 500GB as swap
Frans Pop <email@example.com> writes:
> On Sunday 11 January 2009, Frans Pop wrote:
>>> short: the maximal size of the unlimited partition is specified as
>>> 1,000,000,000 in the recipes, and the numbers there mean MBs, so
>>> that's 1000 TB.
>> OK, but IMO this is more a structural flaw in partman-auto's recipe
>> specification than a bug in partman-auto-lvm. Unlimited should be
>> defined in some other way than "$random very high number which in
>> practice will always turn out to be not high enough".
>> Although with higher numbers we'll also run into overflow problems at
>> some point (and we should probably test for that somehow).
Yes, at above 4 TB in kB based (LVM/crypto) calculation and above 4 EB
in the MB based case. I wonder what would be the overhead
>> I think it would be more logical to specify unlimited as 0 or -1. Or
>> even some string like "none".
> A patch to change this turns out to be fairly trivial. Comments?
> Successfully tested for both regular and LVM partitioning (though not with
> >1TB disk).
Tested with 1.6 TB atomic, and it works OK.
But with a 4 TiB disk:
Unable to determine geometry of file/device /dev/xvda. You should
not use Parted unless you REALLY know what you're doing!
After ignoring this:
Failed to partition the selected disk
This probably happened because the selected disk or free space is too
small to be automatically partitioned.
When back to the partitioning menu:
Virtual disk 1 (xvda) - -1B-1 Xen Virtual Block Device
Which shows we're screwed in this regime anyway, as partman can't
handle disks above 4 TiB. But there is a lower limit as well:
on a 4 TiB - 1 sector disk there are no errors, but half of it remains
LVM VG noc2, LV root - 2.2 TB Linux device-mapper (linear)
> #1 2.2 TB f ext3 /
LVM VG noc2, LV swap_1 - 3.2 GB Linux device-mapper (linear)
> #1 3.2 GB f swap swap
Virtual disk 1 (xvda) - 2.2 TB Xen Virtual Block Device
> #1 256.0 MB B f ext2 /boot
> #2 2.2 TB K lvm
There's a clue in /lib/partman/lib/recipe.sh:
min=2200000000 # there is no so big storage device jet [sic]
Yes, that is 2.2 TB if interpreted in kB. I didn't follow it, though.
All this means to me that the gains are marginal, and could be most
easily achieved by noting infinity as 2000000000. However, noting it
as "inf" or -1, as you did, is only a tiny bit more invasive but much
cleaner, so worth it if we touch this code (note that you can use -a
and -o for logical operations inside expr or [ ]).
All this also means that things should change ASAP from parted up,
because TB scale disks are pretty common nowadays.