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

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

reopen 510544

On Sunday 11 January 2009, Ferenc Wagner wrote:
> Of course you may have solved it independently of my musings.

No, I based the patch I committed on the first part of your analysis.

> Changing k -> K in free size computations as I suggested fixes swap
> size with a 100 GB disk, but not with a 1.5 TB disk.

OK. I only verified it for smaller disk sizes as I was not aware that 
there were two issues.

> That was in my previous mail <[🔎] 87wsd51l6r.fsf@szonett.ki.iif.hu>.  In

Looks like I missed that mail for some reason.

> 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.  Today that's big enough to be considered infinite in
> all practical cases.  However, perform_recipe_by_lvm rescales these
> numbers to mean kBs (by multiplying them by 1000), EXCEPT when the
> number is 1,000,000,000 (our supposed infinity) to avoid instant
> overflow. So when using LVM, the maximal size of the unlimited 
> partition is only 1 TB, and that isn't big enough anymore.  The size
> of the would-be-unlimited partition is effectively capped at 1 TB,
> so on a 1.5 TB disk swap will be 0.5 TB if it's given all the rest.

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).

I think it would be more logical to specify unlimited as 0 or -1. Or even 
some string like "none".

> > Feel free to clone the BR and reopen it (or file a new report) for
> > the 1TB limit issue.
> I still think that the 1TB limit issue is this exact bug report.  That
> 500 GB in the title is 1TB less than the size of the reporter's disk.

When I looked into this I did not read the full history of the BR; the 
analysis in your last mail focussed on the units discrepancy only, so 
that is why I focussed on that.

I'm not willing to take responsibility for the more invasive change of 
your full patch at this point. If someone else want to review and test 
it, that's fine by me. If not, we can revisit it after the release and 
possibly fix it in a Lenny point release.

Reply to: