[14:47] <mnaser> It looks like cloud-init backgrounded resize is blocking.. and any ideas why it can be taking a really long time? Jul  3 14:43:13 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 275.751 seconds
[14:47] <mnaser> That's from 20G to 160GB (with only ~6GB of data)
[14:48] <mnaser> This is on CentOS 6, upgraded to the latest e2fsprogs
[14:48] <harmw> that kernel doesn't support it, iirc
[14:49] <mnaser> harmw: afaik, there is a feature that makes resizing much faster using lazy_itable_init
[14:49] <harmw> centos' kernel is to old to certain resize things
[14:49] <mnaser> hm.
[14:49] <harmw> i haven't looked at this for say 4 months or so though :)
[14:49] <mnaser> Any suggestions in that case? I rather not drop in a kernel that won't get updated, any "updated centos kernel" repos?
[14:50] <harmw> no no, kernels are holy
[14:50] <mnaser> yeah.. i didn't for a while but we had someone provision a 1.2tb disk centos vm and it's taking forever and a half :)
[14:50] <harmw> perhaps centos-plus, though I doubt even that
[14:50] <harmw> well, why on earth would one require a cloudy instance with 1.2TB of storage?
[14:50] <harmw> :)
[14:51] <harmw> (and ofcourse, 'because one can' is a viable answer :p)
[14:51] <mnaser> harmw: our local disk grows with the amount of memry/etc
[14:51] <mnaser> so this is a 32gb instance
[14:51] <mnaser> ex: 1gb gets 40gb... we grow linearly so 32 ends up with 1280gb
[14:52] <harmw> damn
[14:52] <mnaser> yeah but this isnt too useful if i cant figure out how we can solve this
[14:52] <mnaser> i tried e2fsprogs 1.42.6, 1.42.8 and 1.42.10 (latest) with the utils as well but no go
[14:52] <harmw> on a personal note, since when did there become a direct relation between mem/hdd sizes? :)
[14:52] <harmw> thats not a very good thing imho
[14:53] <mnaser> how come?  it helps us not end up with un-used local disk space
[14:53] <harmw> anyway, problem here is resizing takes quite long due to the large disk/fs
[14:53] <mnaser> yeah.. i think it has to do with the old kernel/tooling
[14:53] <harmw> I'm quite positive it was the old (ancient) CentOS kernel in this case
[14:54] <harmw> have you tried ubuntu?
[14:54] <harmw> or fedora?
[14:54] <mnaser> ubuntu boots ultra quick with no problems
[14:54] <harmw> and thats with kernel 3.x?
[14:54] <mnaser> that's why i felt it had to be resize2fs/kernel
[14:54] <mnaser> yup
[14:54] <harmw> yeah, in that case I'm quite positive this boiled down to CentOS' kernel
[14:54] <mnaser> i found this too
[14:54] <mnaser> https://bugs.launchpad.net/bugs/1179610
[14:55] <harmw> shouldnt take to look for them to set 7.0 free though :)
[14:55] <mnaser> it looks like ubuntu had the same issue in 2013
[14:55] <harmw> yea, we had this issue with cirros a while back as well
[14:56] <mnaser> it does look like this got fixed by newer e2fsprogs but that didnt help me
[14:57] <harmw> nah, it still requires a shiny 3.x kernel
[14:57]  * mnaser sigh
[14:58] <harmw> you might want to give centos7 a try, it's not far from gold status
[14:59] <mnaser> pretty sure the stuff we run on centos 6 hasnt yet been fully prepped for centos 7
[14:59] <mnaser> http://elrepo.org/tiki/kernel-lt i want to give this a shot
[15:01] <harmw> ah yes
[15:02] <harmw> well good luck
[15:02] <mnaser> harmw: thanks, entering uncharted territory is fun (not)
[15:02] <harmw> hehe
[15:02] <mnaser> i'll let you know though! :)
[15:02] <harmw> yea, I'd appreciate that