[10:27] <ZaggeO> does anyone know what is the reason that xhci_hcd is compiled into the kernel and is not as a module
[10:32] <mlankhorst> why is it important to you?
[11:29] <ZaggeO> mlankhorst: it sometimes blocks suspend of the kernel and without being a module I can't unload to make suspend work
[11:42] <apw> ZaggeO_, iirc they are compiled in else you cannot ensure that usb3 things are found by that first
[11:47] <ZaggeO_> apw: what might not be found?
[12:09] <ZaggeO_> apw: you mean during bootup or in general?
[12:09] <apw> in general
[12:09] <apw> i believe
[12:10] <apw> as i think usb2 can be loaded in responce to a device, then it will always take everything
[12:10] <apw> and so usb3 is never loaded, something like that
[12:11] <ZaggeO_> apw: it is a module on my debian machines and it works without problems there. It used to be a module on ubuntu too some releases ago
[12:11] <apw> indeed, and we changed it because it was an issue
[12:12] <ZaggeO_> since then I have the issue that my kernel sometimes no longer suspends and I need to reboot
[12:13] <ZaggeO_> and quite often I don't notice it and then the battery runs out in my backpack and when I want to use it again it is empty
[12:15] <ZaggeO_> apw: is there a different stock kernel one could use without the need to compile my own kernel?
[12:16] <apw> all our stock kernels have essentially the same config
[12:17] <apw> you should file a bug for it, perhaps it can be fixed the suspend issue
[12:22] <ZaggeO_> apw: what kind of infos should I attach to the bug report?
[12:27] <apw> everything you said above at least
[13:33] <hallyn> sforshee: hey, so tried out fuse-ext2 in a container.  Created loopback on host with ext2;  created /dev/loop0 in container;  used fuse-ext2 to mount htat.  could only mount read-only.  is that expected?  (I assume so, but am not sure based on your intro email why)
[13:39] <sforshee> hallyn: you have to supply -oforce with fuseext2 to get a rw mount
[13:42] <sforshee> hallyn: also you don't have to mess with loop if you don't want to, you can give it the name of an fs image file
[13:43] <hallyn> sforshee: thanks
[13:44] <hallyn> think i'll set up some package builds in and out of that fs and see how the timings compare
[14:19] <hallyn> sforshee: smoser: wow, completely naive test (timing building of lxc package exactly once) shows fuse-ext2 being faster than the container's native ext4
[14:19] <hallyn> I suspect ocne I start some page cache clearing that'll change,
[14:20] <hallyn> but still that completely belies smoser's argument that fuse can't be good enough :)
[14:20] <smoser> you dont think that runnning all reads and writes through user space is faster than the kernel ?
[14:21] <smoser> if it turns out that ext4 via fuse is as fast as in-kernel ext4
[14:21] <smoser> then... um... that is really bad.
[14:21] <smoser> embarrassingly bad from the kernel ext4 perspective
[14:22] <hallyn> well i didn't compare to a *real* fs :)
[14:26] <sforshee> hallyn: that's interesting, I wonder if that will hold over multiple test runs
[14:26] <sforshee> and if it does I'd really like to know why
[14:28] <hallyn> sforshee: multiple runs, probably.  I'm guessing the data never even hit disk
[14:28] <sforshee> hallyn: it would be more apples to apples to compare ext2 in kernel to ext2 in fuse
[14:28] <hallyn> so bigger runs, where i start swapping page cache, will probably get a hit
[14:28] <hallyn> sforshee: i thought fuse-ext2 was actually doing ext4
[14:29] <sforshee> hallyn: possible, but would it have hit disk in the normal case? I assume you were using loop.
[14:29] <hallyn> Yeah, using loop
[14:29] <hallyn> for the fuse fs
[14:29] <sforshee> I don't think fuse has any driver for ext4. afaik fuseext2 supports ext2 and ext3 only
[14:29] <hallyn> and no, it wouldn't have hit disk in normal case either - which is the confusing part.  
[14:29] <hallyn> hm
[14:29] <hallyn> well ext4 is supposed to be way faster no? :)
[14:30] <sforshee> dunno, there's definitely more complexity
[14:30] <hallyn> anyway i wasnt out to do a *good* comparison this morning;  i only wanted a "this isn't completely unusable" comparison
[14:30] <sforshee> I wonder if cking has any benchmarks for ext2 vs ext4
[14:31]  * hallyn waits for smoser to more explicitly suggest that we should all be using microkernels
[14:31] <sforshee> though these days we're using the ext4 driver even for ext2
[14:34] <cking> sforshee, nope, but I can add them to the mix
[14:34] <smoser> yeah, its caching.
[14:34] <smoser> same reason that loop is faster than direct sometimes :)
[14:34] <smoser> thats the only thing i could figure.
[14:35] <sforshee> smoser: but I think both cases should be cached, that's why I'm confused
[14:35] <sforshee> we'
[14:35] <sforshee> we'll just wait and see what further testing shows I guess
[14:35] <cking> smoser, maybe metadata writes are being cached more when on the loop
[14:35] <smoser> i never understood that.
[14:35] <sforshee> cking: not more than when going through fuse I suspect
[14:35] <smoser> but lots of times people report loop being faster than non-loop
[14:35] <smoser> oh. well. i thikn that 'fsync' doesnt actually fsync
[14:35] <smoser> through loop
[14:36] <smoser> is that the case ?
[14:36] <cking> smoser, the "advantage" of more dirty pages being cached and that extra layer may give some advantage I guess
[14:36] <smoser> i sweare i read that once. that loop devices had no fsync. but i'm clearly in over my head here :)
[14:37] <sforshee> smoser: I don't know for sure, but I'd guess that it only syncs to the backing file and not all the way through to the disk
[14:37] <smoser> right.
[14:37] <smoser> thats what i had thought.
[14:37] <smoser> which would mean a spinning disk would be slower when the fsync was actually forced to go to it.
[14:38] <sforshee> right
[14:39] <cking> i guess we can speculate to the cows come home, whereas using perf may tell us what's actually happening
[14:49] <ev> arges: hi. Would you be able to help me find out if nested kvm is something you guys are willing to support? Running the Touch emulator on Canonistack gives me unhappy results: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347737
[14:49] <arges> ev: hi, taking a look. nested KVM should work, but there are some hardware dependent issues that can occur
[14:50] <ev> in that case, let me get you some more details on the VM
[14:50] <ev> or do you mean the compute node's hardware?
[14:50] <arges> ev: well both will be relevant
[14:50] <ev> presumably the latter :)
[14:50] <ev> ah, right
[14:52] <arges> ev: so what is a bit confusing is that you are running on i386, but the VM is ARM arch? are you emulating?
[14:53]  * ev bangs his head on the desk
[14:53] <ev> let's try this with x86 on x86, shall we
[14:53] <arges> ev: : )
[16:28] <xnox> why shan't we ;-)
[18:23] <xevious> Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version?
[19:52] <Hauke> apw: I created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347879
[20:08] <rtg> Hauke, I'm about EOD, but I'll look at it in the AM
[20:08] <Hauke> rtg:  thanks