Frans Pop <elen...@planet.nl> 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 unused: 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. -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
