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