[10:27] does anyone know what is the reason that xhci_hcd is compiled into the kernel and is not as a module [10:32] why is it important to you? [11:29] mlankhorst: it sometimes blocks suspend of the kernel and without being a module I can't unload to make suspend work [11:42] ZaggeO_, iirc they are compiled in else you cannot ensure that usb3 things are found by that first [11:47] apw: what might not be found? [12:09] apw: you mean during bootup or in general? [12:09] in general [12:09] i believe [12:10] as i think usb2 can be loaded in responce to a device, then it will always take everything [12:10] and so usb3 is never loaded, something like that [12:11] 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] indeed, and we changed it because it was an issue [12:12] since then I have the issue that my kernel sometimes no longer suspends and I need to reboot [12:13] 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] apw: is there a different stock kernel one could use without the need to compile my own kernel? [12:16] all our stock kernels have essentially the same config [12:17] you should file a bug for it, perhaps it can be fixed the suspend issue [12:22] apw: what kind of infos should I attach to the bug report? [12:27] everything you said above at least [13:33] 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] hallyn: you have to supply -oforce with fuseext2 to get a rw mount [13:42] 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] sforshee: thanks [13:44] think i'll set up some package builds in and out of that fs and see how the timings compare [14:19] 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] I suspect ocne I start some page cache clearing that'll change, [14:20] but still that completely belies smoser's argument that fuse can't be good enough :) [14:20] you dont think that runnning all reads and writes through user space is faster than the kernel ? [14:21] if it turns out that ext4 via fuse is as fast as in-kernel ext4 [14:21] then... um... that is really bad. [14:21] embarrassingly bad from the kernel ext4 perspective [14:22] well i didn't compare to a *real* fs :) [14:26] hallyn: that's interesting, I wonder if that will hold over multiple test runs [14:26] and if it does I'd really like to know why [14:28] sforshee: multiple runs, probably. I'm guessing the data never even hit disk [14:28] hallyn: it would be more apples to apples to compare ext2 in kernel to ext2 in fuse [14:28] so bigger runs, where i start swapping page cache, will probably get a hit [14:28] sforshee: i thought fuse-ext2 was actually doing ext4 [14:29] hallyn: possible, but would it have hit disk in the normal case? I assume you were using loop. [14:29] Yeah, using loop [14:29] for the fuse fs [14:29] I don't think fuse has any driver for ext4. afaik fuseext2 supports ext2 and ext3 only [14:29] and no, it wouldn't have hit disk in normal case either - which is the confusing part. [14:29] hm [14:29] well ext4 is supposed to be way faster no? :) [14:30] dunno, there's definitely more complexity [14:30] anyway i wasnt out to do a *good* comparison this morning; i only wanted a "this isn't completely unusable" comparison [14:30] 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] though these days we're using the ext4 driver even for ext2 [14:34] sforshee, nope, but I can add them to the mix [14:34] yeah, its caching. [14:34] same reason that loop is faster than direct sometimes :) [14:34] thats the only thing i could figure. [14:35] smoser: but I think both cases should be cached, that's why I'm confused [14:35] we' [14:35] we'll just wait and see what further testing shows I guess [14:35] smoser, maybe metadata writes are being cached more when on the loop [14:35] i never understood that. [14:35] cking: not more than when going through fuse I suspect [14:35] but lots of times people report loop being faster than non-loop [14:35] oh. well. i thikn that 'fsync' doesnt actually fsync [14:35] through loop [14:36] is that the case ? [14:36] smoser, the "advantage" of more dirty pages being cached and that extra layer may give some advantage I guess [14:36] i sweare i read that once. that loop devices had no fsync. but i'm clearly in over my head here :) [14:37] 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] right. [14:37] thats what i had thought. [14:37] which would mean a spinning disk would be slower when the fsync was actually forced to go to it. [14:38] right [14:39] i guess we can speculate to the cows come home, whereas using perf may tell us what's actually happening [14:49] 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] Launchpad bug 1347737 in linux (Ubuntu) "Kernel nested kvm support" [Undecided,New] [14:49] ev: hi, taking a look. nested KVM should work, but there are some hardware dependent issues that can occur [14:50] in that case, let me get you some more details on the VM [14:50] or do you mean the compute node's hardware? [14:50] ev: well both will be relevant [14:50] presumably the latter :) [14:50] ah, right [14:52] 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] let's try this with x86 on x86, shall we [14:53] ev: : ) [16:28] why shan't we ;-) [18:23] 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] apw: I created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347879 [19:52] Launchpad bug 1347879 in linux (Ubuntu) "Compile problem with external module and 031600rc5" [Undecided,New] [20:08] Hauke, I'm about EOD, but I'll look at it in the AM [20:08] rtg: thanks