[05:27] <akshay> Hello.. Is it possible to shutdown the linux system from a kernel IRQ.?
[09:39] <csurbhi> hello smb :)
[09:39] <csurbhi> is the default option for ext4 fs ordered ?
[09:40]  * apw suspects he'll ask you
[09:40]  * csurbhi looks
[09:41] <smb> csurbhi, it was
[09:41] <smb> but when they added an option, it defaulted to writeback
[09:41] <smb> thats how we got it
[09:41] <csurbhi> but should it not be ordered again ?
[09:41] <apw> smb that is ext3 right?
[09:43] <cking> perhaps we need a per-release table of fs default mount options written up somewhere
[09:43] <smb> apw, yes
[09:43]  * csurbhi is cursing the slow laptop
[09:43] <smb> csurbhi, exactly
[09:43] <csurbhi> ok, i will make one 
[09:43] <smb> cking, The problem was it slipped in
[09:43] <apw> there are two questions, should we change the default back for ext3, and is ext4 affected
[09:43] <apw> i assume 1) is yes, and 2) is don't know
[09:43] <csurbhi> yes, i think ext4 is affected as well
[09:43] <smb> As the default without having an option was ordered and the default with the option was writeback
[09:43] <smb> ext4 has no option as far as I can tell
[09:44] <smb> but I might be mistaken
[09:45]  * csurbhi thinks, ext4 has options of ordered, journal, writeback and now guarded too
[09:45]  * maco agrees with csurbhi
[09:45] <apw> yeah they are mount options though right, which is the default if you don't say
[09:47] <csurbhi> i think that the default mount option is writeback
[09:47] <csurbhi> and it ought to be ordered
[09:47] <smb> You always can tweak them on or after creation as well. I just did not find one compile option as clearly related to that than for ext3
[09:47] <csurbhi> yes, there does not seem to be any compile time option 
[09:48] <smb> Probably for ext4 we should think about which mode is best for us, after figuring out the exact implications
[09:48] <apw> cking, yeah thats not a bad idea
[09:49] <csurbhi> ok
[09:49] <apw> csurbhi, ok this machibne is a standard install.  i took no action
[09:49] <apw> /dev/disk/by-uuid/5fdffa9d-a806-4009-930a-bf637c8f5cfa / ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
[09:49] <apw> it seems to be in ordered mode
[09:49] <csurbhi> ok
[09:50] <cking> apw, and perhaps any known bugs against these fs defaults too
[09:50] <smb> At least that is (between ordered and writeback) the mode that sounded less quick but safer
[09:50] <csurbhi> apw, thanks !
[09:52] <apw> and i note there are no options in my fstab
[09:52] <apw> UUID=5fdffa9d-a806-4009-930a-bf637c8f5cfa /               ext4    errors=remount-ro 0       1
[09:52] <smb> same here
[09:52] <apw> so ... i assume the default is ordered in _lucid_
[09:52] <smb> in Karmic
[09:52] <apw> anyone got a karmic install they can confirm
[09:52] <apw> wicked
[09:53] <smb> So ext4 looks ok (though might get checked whether the other two look more appealing)
[09:53] <apw> smb, sounds liek a job for super-csurbhi to me
[09:54] <smb> Sounds good to me. :)
[09:54] <cking> perhaps we need to keep an eye on the default mount options over the lucid alpha/beta cycles too
[09:54] <csurbhi> i think ordered with barrier=1 is the best
[09:54] <csurbhi> or safest
[09:55] <smb> csurbhi, So if you can get us a dummy-style wrapup of the pros and cons of those to the kernel team list? ;-)
[09:55] <csurbhi> smb, sure i will do that today :)
[09:55] <cking> cool
[10:01] <csurbhi> smb, so few questions ..need your help !
[10:01] <smb> No problem
[10:02] <csurbhi> can you please tell me the tasks that are involved in taking a lead on a stable kernel ?
[10:02] <smb> So have you cloned the upstream repo
[10:02] <csurbhi> not yet
[10:02] <smb> I guess that would go first
[10:02] <csurbhi> ok
[10:03] <smb> We got up to 2.6.31.9 in the ubuntu Karmic tree
[10:03] <smb> If unsure you would see that by the subversion number in the makefile
[10:03] <csurbhi> ok
[10:04] <smb> So basically you look at the changes between 2.6.31.9 and 10 and then at those between 10 and 11 (which is easy as its only one patch)
[10:04]  * csurbhi is cloning the tree
[10:04] <csurbhi> ok
[10:05] <smb> When you look up the mails Leann wrote, you can see there is one bug report related to each update from stable
[10:05] <smb> You can take the things she wrote in the mail and the bug report as a reference 
[10:05] <csurbhi> ok
[10:07] <csurbhi> and then ?
[10:09] <smb> You do a review as you did with the ext4 patches and then send an email like Leann which announces the update and all (including your review notes)
[10:10] <smb> At the same time have the patches applied to a Karmic branch of yours and push that to your repos for review
[10:11] <csurbhi> ok
[10:11] <smb> During that process you might find some patches already applied. There it depends on whether we got that through a security update or a sru/before release. In the case of a security release you drop the upstream stable patch
[10:12] <smb> otherwise you revert the one we carry and apply the new one. But I think you just ask again when that happens
[10:13] <csurbhi> yes, i will do that.. so basically the patch should mention whether its come from a SRU or security ?
[10:15] <smb> Its part of the process to find out. When we apply it to a tree it usually has a CVE number in the description. But you also can look into the changelog to see whether the patch was part of *-proposed or *-security updates
[10:15] <csurbhi> ok, thanks :)
[10:15] <csurbhi> one more question, last time i got the patches directly from your dir.. 
[10:16] <csurbhi> are the patches stored in somewhere ? 
[10:18] <smb> That is what you download from the 2.6.31.y repo. I usually export the range from there and apply them to a working tree in Karmic for myself. Or you have it as a remote and cherry pick them. But the source is always the upstream repo
[10:19] <csurbhi> so you get the patches out of the kernel 
[10:19] <csurbhi> ok
[10:21] <gnarl> csurbhi, If you look at the 2.6.31.y tree. That is an upstream tree which has been branched of 2.6.31 and then gets the stable patches applied.
[10:21] <csurbhi> ok
[10:22] <gnarl> So you can easily get a range of patches that are new
[10:22] <gnarl> There are tags on that tree for every release
[10:22] <gnarl> so a "git log v2.6.31.9..v2.6.31.10" works
[10:24] <csurbhi> ok
[10:27]  * csurbhi thanks gnarl profusely :)
[10:27] <gnarl> csurbhi, Don't worry too much about the later steps. You can get back about them when you are there. The first thing is to have the upstream tree, extract the patches that come as new ones and look over them making your notes. 
[10:27] <csurbhi> ok
[15:01] <apw> smb, you know that fix you did way back when for the mmc exploding on suspend/resume
[15:01] <apw> did anything come of that?
[15:02] <smb> apw, Nothing. And it reminds me to try out latest Lucid to see whether it can still erase on resume
[15:02] <apw> smb could this be the fix for it?
[15:02] <apw> commit 5fa83ce284a4b7cd9dcfadd01500b0ed4ab9b740
[15:02] <apw> Author: Adrian Hunter <adrian.hunter@nokia.com>
[15:02] <apw> Date:   Fri Jan 8 14:43:00 2010 -0800
[15:02] <apw>     mmc_block: fix queue cleanup
[15:03] <apw> this sounds a bit like a fix for what you were seeing to me
[15:03] <smb> apw, Lemme look at that
[15:06] <smb> apw, Yeah, it looks pretty similar to what I remember. 
[15:06] <smb> Both the description and the patch
[15:07] <apw> smb, so should i be dropping yours in favour of that?  its coming in via stable for 32
[15:08] <smb> apw, I guess yes. It likely should not apply with mine on. Right?
[15:08] <apw> it seems to collide only on the comments amazingly but feels like a bad idea to fix it
[15:09] <apw> ok will try dropping yours and applying this one
[15:09] <smb> apw, Yeah. Interesting. But yes, drop mine and I test with that kernel
[15:10] <apw> obviously a more successful approach :(
[15:13] <smb> apw, As long as the problem is fixed I don't care. But I obviously must remember that one can sneak into any place through mm :)
[15:15] <apw> heh yeah ... a side road round a road-block and no mistake
[16:51] <apw> smb, we doing the review today?
[16:51] <smb> apw, yup
[16:55] <apw> bah
[18:00] <ivoks> apw: ping
[18:00] <ivoks> apw: bug 474660
[18:00] <ubot3> Malone bug 474660 in linux "drbd8-utils not dependent on drbd8-source" [Medium,Triaged] https://launchpad.net/bugs/474660
[18:00] <ivoks> apw: that's actually bug in karmic