In this case, the current behavior is actively destructive to the partition table on disks over 2 TB - critical data loss bugs would be RC bugs in scope for a stable update, and so are also probably in scope for work at this point in the process. While I agree that maxing out the partition at 2 TB is far from ideal, it's much better than the status quo of destroying the usability of the disk. We don't have a way to use the disk size in deciding whether to install cloud-initramfs-growroot; while our images are 10 GB (sparse), they are often used with much larger disks.
It's already a common customer desire on GCE to want disks over 2 TB, such that we have it in our test suite (which caught this issue). During the Jessie lifecycle, this need will grow across all environments.
There's no way we can safely use cloud-initramfs-growroot with the current cloud-utils in stock GCE images, and other clouds which offer large physical disks should probably be cautious in the same way. If adopting upstream's fix is deemed infeasible for Jessie and wheezy-backports, at least put in a minimal equivalent fix of your own design where it maxes out at 2 TB. Anything somewhat sane and non-destructive is better than automated accidental destruction.
- Jimmy
On 10/22/2014 07:47 AM, Jimmy Kaplowitz wrote:
> Hi,
>
> Looks like growpart and therefore cloud-initramfs-growroot fails
> horribly on disks over 2 TB, resulting in harmfully shrinking the
> partition size:
>
> https://bugs.launchpad.net/cloud-utils/+bug/1259703
>
> We'd love to use cloud-initramfs-growroot or an equivalent feature, but
> this behavior is of course a problem since our disks often exceed 2 TB.
> Failing to go above 2 TB is okay given the nature of MBR, but preventing
> the disk from being usable is different. Zigo / Julien / *, is there any
> change you could get the fixed upstream version into jessie and
> wheezy-backports soon?
>
> Note this bug is in no way GCE-specific, even though I noticed it in
> that context.
>
> - Jimmy
Jimmy,
At this point in time, just right before the freeze, I think it's best
to just backport the fix. So I've cloned upstream BZR repository to have
a look at the commits. And version 0.27 is very different from version
0.26, so it'd be hard to backport the fix. However, you may have noticed
that the fix isn't great anyway: it just limits the resize to 2TB,
leaving the rest of the HDD as unused (well, of course, because the MBR
doesn't support it, you'd need GPT support for that...).
So at the end, I'm not sure I want to this kind of dangerous work just
right before the freeze. I'd prefer to mark this as a known issue, and
make sure our users don't use HDD size >= 2TB, which is useless anyway
with the current state of cloud-utils.
Though, one interesting feature of cloud-utils 0.27 is that it seems it
now can handle GPT partition tables. Which would be a nice thing to
have, but really, just right before the freeze, I think it's too
dangerous to do an update, especially considering that it still has open
bugs, and that we wont have time to do enough testing.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-cloud-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 544723DC.3@debian.org" target="_blank">https://lists.debian.org/[🔎] 544723DC.3@debian.org