cjohnstonasac can you please op me in both -core- channels14:53
stgraberslangasek: can I get the URL? (I don't think I've got a whole lo to say though, just personal interest as I had to deal with that mess all too often)15:01
cjohnstontsimpson-uds: ping15:01
slangasekstgraber: https://plus.google.com/hangouts/_/76cpiir5ivpt1ft8q95eojbjoo15:01
xnoxblueprint URL: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-dmraid2mdadm15:01
xnoxpad URL: http://pad.ubuntu.com/uds-1311-core-1311-dmraid2mdadm15:01
tsimpson-udscjohnston: \o15:01
cjohnstontsimpson-uds: do you run udsbot ?15:01
cjohnstontsimpson-uds: can you please have it join -core-1 -core-2 and -design-115:02
tsimpson-udscjohnston: I can, but it won't do much without some chanserv magic15:02
cjohnstontsimpson-uds: I did it in -design-1 I'm waiting to do it in here15:03
asaccjohnston: let me know iif its good15:04
slangasek"Almost British"> lol15:04
asacanyone else?15:04
apwxnox, you are visible here15:05
arges-udsis the video live15:05
apwarges-uds, t'is for me15:05
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Transitioning to use MDADM by default for some of the FakeRAID devices | Url: http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/
apwsmb, i assume it does not work at all righ15:18
apwsmb, i assume it does not work at all right now even, so someone has to fix it if we can15:18
apwdm_raid45              76611  015:19
apwit seems to be loaded on my non dm-raid45 system15:19
stgraberthat's unfortunate, would have been nice to get some stats...15:20
apwstgraber, stick a work-item on us to figure out if we can tell, it maybe i have done something odd on this system to make this occur15:20
smbapw, Do you have dmraid installed15:20
smb(the user-space)15:20
apwsmb, i would assume so indeed15:20
apwsmb, yes i do15:21
apw(the userspace)15:21
apwso it maybe triggered by that, so as i say, lets get a WI to investigate if we can mine launchpad bugs for S to get stats or not15:21
cjwatsonindeed, on server images dmraid should generally only be installed if dmraid is actually in use15:22
cjwatsonI suspect kernel engineers are outliers :-)15:22
apw(yeah as i say assume it is me fiddling on this issue which has gotten me here)15:22
apwand lets investigate15:22
* apw sends some large vicious looking people to visit with xnox15:23
xnoxcjwatson: thanks.15:23
xnoxapw: =))))15:23
xnoxapw: if they come with harddrives and motherboards that's fine.15:23
apwxnox, doesn't that depend if the failure mode is "not boot" or "eats my data"15:25
apwsmb, are you going to be investigating if you can back the old userspace with the builtin mdadm targets instead ?15:26
smbapw, that might be a plan b I guess15:27
cjwatsonI suspect that the grub2 transition should not be regarded as a model here15:27
smbhm better than not working15:27
apwsmb, if it makes sense, maybe we should at least evaluate it15:28
smbapw, agree15:28
arges-udsAre there going to kernel config changes? or will dm raid still be built as modules?15:28
xnoxarges-uds: still build modules by the looks of it for dm-raid.15:29
apwarges-uds, that will depend if we are able to map the dmraid userspace to the new ones15:30
smbarges-uds, there is dm-raid and dm-raid4515:30
smbthe latter is the special one we want to drop15:30
arges-udsok gotcha15:30
arges-udsnow finally get the video response15:31
arges-uds: )15:31
xnoxcjwatson: so far I have been told to do a clean switchover, without a fallback (for intel raids, and ddf)15:31
apwthere is quite some lag, not the 7s jono suggested15:31
slangasekhow much?15:34
apwxnox, there is a middle case, were might be able to back the dmraid (non-intel) using 'dm raid' not 'dm raid4-5' on the kernel side15:34
apwslangasek, feels more like 30s at least15:34
slangasekhmm :/15:34
slangaseklag on IRC> yes, people should just join the hangout instead :)15:35
apwi suspect the lag is proporionate to the distanve between the originator and viewer15:35
apwslangasek, heh, maybe so but they are doing just fine over there15:35
stgraberwe definitely still have room in the hangout, so just join :)15:35
apwxnox, we have a WI for that now already15:36
apwsmb, only need that if we have to move people up to 14.04 on 12.04 and that breaks them15:38
smbapw, ERrm /me fails to parse15:39
cjwatsonwell ... if people aren't used to having to use UUIDs by now ...15:39
cjwatsonbut yeah, a quick safety check wouldn't hurt15:39
apw14.04 will replace all the lts-backport kernels on 12.0415:39
cjwatsonxnox: I wouldn't say it happened without *any* bugs :-)15:40
apwwe need to not break that15:40
cjwatsonBut they should be shaken out by now, given it was, er, edgy or so?15:40
smbapw, Ah ok... So if t kernel has no dm-raid45 we have to backport the new dmraid (or partions of)15:40
apwsmb, that indeed15:40
apwso it might be easier to make dm-raid45 work here you never know15:41
* smb grubles15:41
apwnot that we shouldn't migrate people non the less on real 14.04 regardless15:41
xnoxcjwatson: =)))) you are the first one to mention there actually were bugs with that upgrade. (/dev/sda1->UUID)15:41
apwsmb, for us to discuss now we know the issues15:41
* apw likes the idea of mapping over, if that works on all kernels back to P's on P15:42
* apw slaps self for rath15:42
* apw slaps self for ratholing15:42
cjwatsonxnox: Don't get me wrong, considering its complexity it went remarkably well15:42
apwsmb, yeah we should likely only have the module enabled in the lts-backport-trusty and _not_ in the real 14.04 kernel15:44
apwif we are forced to have it for that kernel15:45
apw(the module == dmraid4-5)15:45
apwto prevent 14.04 having the same problem15:46
apwslangasek, we normally do them 3-4 weeks after, but not recommending htem to the first point release15:46
slangasekah, actually 15 minutes to the next session15:50
smbGreat, enough time to go downstairs to the coffee machine15:51
pittislangasek: are you driving the TRIM hangout?15:58
slangasekpitti: ogasawara is15:58
pittiogasawara: probably easiest to just put the URL here?15:59
ogasawarapitti: you have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en15:59
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Enable automatic trimming of SSD drives | Url: http://summit.ubuntu.com/uds-1311/meeting/21974/core-1311-ssd-trimming/
ogasawarastgraber: https://plus.google.com/hangouts/_/72cpike5563pcehdf7qi12a2o0?authuser=0&hl=en16:02
pittistgraber, ogra_, xnox: ^ if you want to join16:02
ogra_pitti, i cant, running the bootsplash session myself next door16:03
pittiogra_: just FYI, not critical16:03
xnoxpitti: i'm joining encryption session.16:03
xnoxpitti: i think we are mostly aligned on the topic - i.e. cron it.16:03
pittixnox: ack, thanks16:03
argesi can see video16:05
chilukso I disagree with using fstrim16:10
chilukI think we should be using discard.16:10
chilukfrom the benchmarks I've seen that discard does not actually trim in real time, but marks blocks for later trimming16:11
chiluk https://patrick-nagel.net/blog/archives/33716:11
chilukapw we the statistics I see are that discard does not affect writes because of caching in the vfs layer16:14
apwchiluk, come join16:14
xnoxall other core sessions finished =)16:49
xnoxterrible lag on the video16:53
stgraberxnox: so I think slangasek expressed an interest for that mountall workitem in the past, so it's probably worth discussing this with him16:53
stgraberxnox: basically the plan is to have mountall remount any mounted fs where the existing flags don't match what's listed in /etc/fstab16:53
chilukI just realized something.16:53
xnoxstgraber: why wouldn't they?16:53
stgraberxnox: and in the case of /, we'd want to only do a single remount, so have any missing flag added at the same time we remount it rw16:54
xnoxstgraber: mountall reads /etc/fstab in the initramfs case.16:54
chilukfor phone it may be beneficial to only run fstrim when plugged in16:54
chilukpitti, ^^16:54
stgraberxnox: I believe we at least had the case of /dev/pts not having matching mount options and that's what triggered that discussion originally16:54
pittichiluk: same for laptop actually, but it's a trade off16:55
pittichiluk: you could easily miss a few cron cycles if you mostly run on battery16:55
chilukI still like discard better for normal use.16:55
xnoxstgraber: it was non-matching in initramfs-less case as I far as I remember (and hence things breaking for infinity and his powerpc machines), but yeah in the initramfs-less case /root will have wrong/non-matching flags.16:55
stgraberchiluk: well, phones will run with discard, so fstrim will be a very fast noop there anyway16:55
pittichiluk: and of course we cannot control this at all with discard, which we already agreed to on the phone..16:55
stgraberxnox: ah yeah, that could have been.16:56
xnoxstgraber: pitti: did you agree for discard mount option on the desktop as well ?16:56
stgraberxnox: no, we agreed on it for the phone. For desktop it's pending benchmarking by cking16:56
xnoxstgraber: ok. cool.16:56
pittixnox: right; chiluk brought up that it might not actually be synchronous any more on current kernels16:57
xnoxpitti: nice =)16:57
chilukyeah I'm fairly certain the discards get cached in the vfs like everything else.16:57
chilukat least that's what the benchmarks I've seen imply.16:57
pittichiluk: still a bit sceptical; http://goo.gl/1mdjzl benchmarks show 25% penalty on a "compile" test case16:58
pitti(which would create and remove lots of small temp files)16:59
pittibut then again I don't trust this benchmark much16:59
pittimany numbers are very implausible16:59
xnoxpitti: what are typical phone usage patters? write only, delete occasionally.17:00
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html
pittixnox: yeah, deletion mostly for downloads/browsing, I suppose17:00
xnoxright, all the media / streaming caches.17:01
pittixnox: but in general you write a lot less on the phone, so keeping it "always clean" on small file systems which are mostly full is the more pressing concern there17:01
xnoxpitti: well, my laptop is ssd and I'm using "discard" mount option, and I haven't tried / compared with cronned fstrim.17:02
pittixnox: that's the kind of benchmark we want to do17:02
xnoxso far i am happy, but it is nowhere near full (disk uage)17:02
pittixnox: i. e. delete with lots of little, and a big file, with and without discard17:02
pittithe discard overhead shouldn't really depend on how full the fs is?17:03
pittithe "do it once a week" performance certainly does17:03
ogra_if you measure this on a phone, please take wakeups and battery usage into account17:03
ogra_thats my only concern about doing it cronned17:04
pittiogra_: that woudl rather be my concern about doing "discard", but yes17:04
pittiogra_: but the summed workload should be the same17:05
ogra_well, indeed, if discard can cause wakeups in sleep state that would be bad17:05
pittiin the end you need to trim all deleted blocks, either in one big chunk or in lots of little steps17:05
ogra_i#m specifically talking about waking up from suspend to run the cron job17:05
pittiogra_: no, it's pretty much tied to removing, which is already keeping the process and drive awake17:05
ogra_if the device is fully on thats a no brainer17:05
pittiogra_: but on the phone we already decided for "discard" anyway for other reasons17:06
pittiogra_: the benchmark/question is only about desktops at this point17:06
ogra_on arm the system can simply wake only parts of the peripherial devices ... if cron kicks in (the clock is always on on arm) it might cause a wakeup on the lower system level to just do the removing17:06
ogra_ah, k17:07
ogra_(sorry, didnt follow the session, if discard is set by default thats fine)17:07
slangasekstgraber, xnox: mountall> there's an open bug report on mountall about this17:12
pittican't find ^ right now17:17
pittiI looked at some with plausible titles, but they sounded different17:18
jderoseis this the correct room for "Enable automatic trimming of SSD drives"?17:21
ogra_jderose, it was ... for the last hour17:22
pittijderose: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming has the session notes and WIs17:22
jderoseah, oops, guess i'm watching the recording :P17:22
jderosepitti: FYI, System76 has been working toward enabling discard on imaging time. in our experience, on modern SSDs, there is very little overhead to discard. deletes are slower, but deletes are extremely fast anyway. So personally, we're leaning toward discard over cron + fstrim17:24
jderosealthough on some older ssds, discard is very expensive17:24
jderose(some anyway)17:24
xnoxjderose: cool, thanks for input.17:25
pittijderose: thanks17:25
xnoxjderose: i believe discard is now available in d-i, thus one can preseed discard already today, i think.17:26
pittixnox, stgraber, chiluk: something crossed my mind: on upgrades, when we alter fstab, we should probably call fstrim once17:26
jderosexnox: gotcha, but we don't need it. we have very flexible imaging software :)17:26
pittiotherwise we won't trim the already existing free blocks, just the future ones17:27
pitti^ added to BP17:28
stgraberpitti: yep, that makes sense17:28
xnoxpitti: well one wants to run fstrim on first reboot once the file system is mounted with discard.17:36
pittixnox: self-destroying upstart job? (eww)17:37
pittixnox: perhaps better let the cron job do that?17:37
xnoxjderose: is it open sourced?17:38
jderosei'm still listening to the recording, but this point was just raised: that using discard can be a better choice when an ssd in fairly full, so that you don't have inconsistent performance (degrading performance through the week till fstrim is run). this is another reason that System76 is leading toward discard17:38
xnoxpitti: hm. well we can leave a flag file (similar to reboot flag) and clear it once we successfully fstrimmed.17:38
pittixnox: right; the cron job could watch for that?17:39
jderosexnox: no, it's not. i'm not the man who writes the paychecks, not my call :P17:39
xnoxpitti: yeah, and it would be @reboot type of job.17:41
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Cgroup manager for LXC | Url: http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/
cjwatsonxnox: discard> well - except that when I tried to SRU-QA that I found that it was broken17:57
cjwatsonxnox: I've been waiting for git.d.o to come back so that I can check whether it's fixed in Debian and if not fix it there17:57
cjwatson(It's definitely on my plate)17:57
xnoxcjwatson: well mjt wrote a perl script to re-assembled the raid array, so all data is restored. last time I looked it was getting rsynced to a new VM.17:58
xnox(literarly looking up bad blocks from the kicked out drive and doing writes)17:59
cjwatsonxnox: Yeah, I'm following #alioth too :-)18:00
xnoxcjwatson: s/git.debian.org/moszumanska.debian.org/ fetches d-i repositories for me =)18:01
cjwatsonxnox: I'm not touching the new host (even "read-only", which will probably in practice generate some writes) until they say it's OK, in case I disturb the recovery process18:01
cjwatsonI'd advise doing the same ...18:01
chilukpitti, that makes sense, although you need to be careful on which side of the reboot that happens18:02
stgraberslangasek, ogasawara: which of you is start the hangout?18:02
ogasawarastgraber: slangasek is18:02
cjwatsonEven though I am itching to push stuff18:02
pittistgraber: would this by any chance be compatible to systemd's cgroup handler/service? that would unblock us being stuck at v204 (and at any rate, with this we would need to port logind 204 to that new service)18:11
deppsystemd's cgroup implementation is perfectly stackable18:15
deppsystemd runs fine inside of containers18:15
pittistgraber: ^ I added notes to the pad18:16
deppso, you haven't looked at the api but claim it "wasn't flexible" enough?18:16
deppare you aware that libcgroup is not maintained anymore upstream at RH?18:17
hallyn_depp: yes, we are.  the cgroup daemon in libcgroup was unworkably racy18:17
depphallyn_: and now you want to make use of libcgroup nonetheless?18:17
deppare you aware that dbus just uses a UNIX socket too? you could just create one of those and mount it into the container, too18:18
apwdepp, you should join the hangout18:18
hallyn_depp: only of some of the userspace commands, and we're not sure.  actually lmctfy is what i was going to leverage18:19
xnoxdbus supports starting private socket. and let your apps talk to you via private socket.18:19
xnoxwithout actually having a session/system dbus.18:19
deppupstart itself even uses a private dbus socket...18:19
xnoxeven an annonymous one.18:20
deppare you aware that there are no real linux implementations that could run inside a container that doesn't come with libdbus anyway?18:20
deppbecause dbus is based on unix sockets, it can do *anything* unix sockets can do, as good and well as any other IPC...18:21
stgraberdepp: I have a whole lot of users running minimal busybox based environment who'd beg to differ18:21
pittistgraber: you want to have cgroup management tools in that environment, but not libdbus?18:22
slangasekpitti: I don't think that's the argument18:22
apwpitti, he wants to be able to pass it into a container, and that pass it to a second container which consumes it, without the intermediate needing anything including libdbus18:23
pittistgraber: but in either case, it seems that our systemd-shim could take the org.freedesktop.systemd1.StartTransientUnit call on D-BUS and translate it to our service, so we'd be back to being compatible18:23
deppsooo, you want to come to a conclusion here, admit that you have neither looked at systemd's cgroup stuff, nor on the google thing, do not have any idea about dbus? how's that going to work?18:23
pittiapw: ack18:24
stgraberpitti: yes, that's what I suggested earlier, having a small dbus service that just wraps our generic API to systemd's, then logind could just use that18:25
pittistgraber: right, we have that already for suspend/reboot/etc.18:25
pittistgraber: great18:25
pittimeh, pad seems down18:25
slangasekyep :/18:25
* apw pokes people18:27
hallyn_depp: have looked at lmctfy;  systemd has told us at plumbers directly that only one pid on host should control cgroups.  please write more concisely what exactly you're advocating for.  we're just gathering reuirements and options here.18:32
hallyn_(last time i looked deeply into dbus, it had a bad bug in how it passed lsm creds;  fixed that, but it did not inspire confidence)18:32
slangasekhallyn_: if we're using a private socket, should all be fine18:33
hallyn_slangasek: yeah i'm pretty sure i followed up at the time (2010) to get the bug fixed :)18:41
deppwhat about devices that come and go, whose major/minor need to be updated in the cgroup properties? afaik google doesn't do dynamic devices...18:46
deppwhat about propagation between groups? any thoughts on that?18:46
slangasekdepp: I don't understand your question.  the major/minor of any given device is fixed, even if the device node comes and goes; the only exception to this is within containers themselves, where lxc diverts console devices18:49
deppslangasek: the major/minor changes on each plug, you cannot use it for configuration18:51
slangasekthe major/minor changes only if the device name also changes18:51
hallyn_that's related to what Michael Warfield is working on for lxc.18:51
deppslangasek: that is non-sense, sorry, that's now how it works. the kernel just allocates the lowest free minor for most devices these days18:51
slangasekyes, and the device *name* reflects the major/minor18:52
hallyn_(well that dpeends on udev rules :)18:53
slangasekbut if the concern is for devices that don't have persistent names, then sure, that's back to what hallyn_ says that Michael is working on this18:53
pittihallyn_: no, udev rules don't set/change device names18:56
hallyn_pitti: they soon might :)18:57
pittihallyn_: ??18:57
hallyn_pitti: udev rules may fire and link devices into /dev/.lxc/$container18:57
hallyn_pitti: that's part of what Michael is working on18:57
pittihallyn_: well, links, yes, but not names; the kernel defines device names18:57
hallyn_pitti: eh, the kernel wants to tell me that it defines devices names but that i can't rely on them.  so i don't care :)18:58
pittihallyn_: the "rely" part are persistent symlinks :) (and we've had them for ages)18:58
pittibut yes, in general device names are pretty uninteresting in most cases18:58
pitti(for storage, USB, etc.)18:59
hallyn_pitti: the specific problem Michael has is a 4-port (or so) serial board,18:59
hallyn_where the specific ports are randomly assigned at boot, apparently18:59
hallyn_lunch - \o18:59
pittilunch, too; thanks guys!19:00
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Track: Core | Discuss reconciling the Qt requirements for Ubuntu vs. Kubuntu | Url: http://summit.ubuntu.com/uds-1311/meeting/21986/core-1311-qt5-versions-in-ubuntu/
janimono video yet for the Qt session?19:04
Mirvshoud be in 1min (starts :05), but no idea yet19:05
* sil2100 is waiting as well19:05
slangasekcome one, come all19:06
MirvKubuntu people?19:08
pmcgowanproposal is Qt 5.219:11
MirvSaviq: joining?19:15
sil2100Saviq: ping! Can you join?19:15
greybackupdated Qt version does not break public API or ABI, only the private stuff19:15
mzanettiMirv: unity uses some internal headers from qtdeclarative. not too much but we have a couple of patches to do on every upgrade.19:16
rsalvetigreyback: only private in the 5.x series?19:16
greybackrsalveti: yes. There's no api guarantee with private stuff. But public has19:17
rsalvetiright, then we need to reduce that19:18
Mirvmzanetti: ah, ok19:18
Mirvand sorry, the hangout toolbox not starting for me so I don't have a name tag19:19
sergiusensslangasek, add an action item to add the action item on the other session :-)19:49
* sergiusens jokes19:49
xnoxsergiusens: -EJOKERAISED19:49
=== ChanServ changed the topic of #ubuntu-uds-core-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-2/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-2.html

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!