2.6.32.x long-term kernel

June 09, 2010 — BarryK

I have posted Greg's response about using ext4 in the 2.6.27.x kernel:
http://bkhome.org/archive/blog2/201006/compiling-262747.html

Hmmm, food for thought. Yes, I do want Wary to be able to be built with this kernel. Perhaps I should set the default for any ext4 partition to be mounted read-only. Perhaps a popup warning not to use ext4.

The latest kernel that is planned for long-term support by Greg is 2.6.32.x. So, I think that I'll release two Wary's, built with 2.6.27.47 and 2.6.32.x, and attempt to compile all the analog drivers on the latter -- that will be "interesting".

I wonder though, if Greg is just being cautious about his advice on ext4. Perhaps all the ext4 patches to 2.6.27.x have made it usable -- as Greg commented, it would be a good idea to contact the ext4 developers, in particular anyone involved in patching the 2.6.27.x kernel -- I look in the changelog, find any contact details.

Comments

2.6.27.x ext4
Username: BarryK
Hmmm, looking back through the changelog, there have been lots of ext4 patches. Maybe Greg is just being ultra cautious. Anyway, I have followed his advice and sent emails to ext4 developer guys who have contributed patches to 2.6.27.x. It will be interesting to read their opinions. Username: 9 Jun 2010, 8:43
"01656"114.129.167.148'ext4 backport"Iguleder"Barry, if all ext4 fixes got ultimately backported to the stable 2.6.27.x tree, it should be just fine, theoretically. It should be as stable as 2.6.33.5 with ext4. Anyway, even if it isn't ... maybe it's possible to transplant the ext4 of 2.6.34 on 2.6.27.x ... I think I'll try to do that, just for fun."9 Jun 2010, 13:48"01656"79.181.126.174'Backport worked!"Iguleder"Barry, I was able to backport the ext4 code from 2.6.33.5 to 2.6.27.47. The squashfs patches you used don't work for me, so I applied them manually, I went over all files. The line numbers are incorrect or something. What I did is very simple, took about half an hour. 1) I extracted the vanilla 2.6.27.47 and the vanilla 2.6.33.5. 2) I downloaded the standlone aufs2-27 through git. 3) I applied aufs2-base.patch, aufs2-kbuild.patch and aufs2-standalone.patch. 4) I copied over Documentation, fs, design and include from the Aufs2 git directory. 5) I applied the ext4 rename patch. 6) I deleted fs/ext4 and put the fs/ext4 of 2.6.33.5 instead. I think I didn't notice any extra files. 7) I copied over the 2.6.33.5 fs/squashfs. 8) I applied the squashfs patches manually, just searched for the line to put stuff after, put them and saved. 9) I applied printk.c.patch. I'm compiling the kernel with Aufs2, ext4 and Squashfs 4. Needs testing, though. bzImage is ready, clean compile, need the modules now. So far I see ext4 compilation failed, there's a big difference between 2.6.27.x and 2.6.33.5 in this area. Aufs2 and Squashfs compilation passed. I'll try to mess with ext4 a little. Maybe there is a way to backport that shiny new ext4 after all. I think I'll try to build a Quirky/Puppy with this thing, I just don't really know how to put this thing in Woof."9 Jun 2010, 14:48"01656"79.181.126.174'Re ext4 backport"BarryK"Heh heh, I understand your keen-ness! When I went through the changelog, there were lots of ext4 patches, going right back. Even 2.6.27.47 has some -- so I would say that this kernel is being actively used with ext4 filesystems and is perfectly usable. I expect feedback from the ext4 developers on that soon. Note that the current release version of Woof is a bit broken when building with that kernel. I had to fix a few things, for example although it is an old kernel it has Squashfs4 which breaks some scripts. Another one: needs an older version of module-init-tools. I will upload a fixed Woof soon. Username: 9 Jun 2010, 15:19
"01656"114.129.167.148'The ext4 patch is broken"Iguleder"The ext4 rename patch is broken. Noticed this just now. It patches all files except one file, fs/ext4/super.c. I tried the patch the kernel devs used to rename at the time, it doesn't work too. It failed in everything except 2 lines lol By the way, I made patches with my 2.6.33.5 Squashfs and the git Aufs, do you want me to upload them? I think the Squashfs patch could be pretty goddamn useful ... who knows, should be better than the older SFS4."9 Jun 2010, 15:26"01656"79.181.126.174'Feedback from ext4 developers"BarryK"Ok, it is not good news. Aneesh, who has been contributing ext4 patches right up to 2.6.27.47, has this to say: [i]I also wouldn't recommend 2.6.27.x. Ted (ext4 maintainer) also expressed a similar concern.[/i] Theodore, who is one of the main kernel developer guys and who has contributed many ext4 patches, says this: [i]There are a large number of ext4 bug fixes which have not been backported to 2.6.27.x, simply because it's been Too Hard. For lightweight use, you'll probably be OK -- there are people who are using 2.6.27.x with ext4 and I haven't heard screaming about lost data --- but I do have known test cases that will cause ext4 in 2.6.27.x to result in file system corruption and/or kernel panics.[/i] Username: 9 Jun 2010, 15:38
"01656"114.129.167.148'Different approach"Iguleder"There's a different approach, too. If 2.6.27.47 doesn't like ext4 ... you can take 2.6.27.47 and a newer ext4 module. There's a very high chance it won't work ... but what if you compile 2.6.27.47 with everything, including the renamed ext4dev and replace ext4.ko with a kernel module from a newer kernel? If you read what the help for "Module versioning support" says, there *is* a chance that this will work. It says "sometimes", and that's more than enough for me. If it shows any error about different kernel versions, I think it wont' be too hard to patch the kernel to remove that ... just as your printk patch does. The kernel headers are totally different and even the compilation asks for some stuff that exist only in other parts of the kernel ... but if it's a module, all that code should go to the kernel module. Theoretically, I mean. Let's hope it's possible to get this working practically :D I think I'll try to compile my 2.6.27.47 with everything and transplant a 2.6.33.5 ext4 module."9 Jun 2010, 16:34"01656"79.181.126.174'Found a good patch"Iguleder"First of all, sorry for the annoynce, too excited about Wary and this little kernel project :) I also tried another patch from the kernel git repo, which didn't work either. Then, I found a working ext4 rename patch from Arch. It doesn't have the errors your patch produced. http://repos.archlinux.org/wsvn/packages/kernel26-lts/repos/core-i686/linux-2.6.27-ext4-rename-ext4dev-to-ext4.patch It applies cleanly and seems better. Here are my other patches: http://iguleder.net.ms/2.6.27.47/squashfs-2.6.33.5-2.6.27.47-backport.patch (squashfs from 2.6.33.5 backported) http://iguleder.net.ms/2.6.27.47/aufs2-27-git-06092010.patch (aufs2, the .27 branch, has all patches and extra files included)"9 Jun 2010, 20:03"01656"109.67.112.97'kernal min for ext4"scsijon"not planned to to duplicate what I put elsewhere (sorry barry) see wikipedia under ext4 and look at kernal versions for explanation http://en.wikipedia.org/wiki/Ext4"17 Jun 2010, 10:16"01656"180.181.38.179'squashfs4 in 2.6.27"technosaurus"tracked down another possible squashfs4 patch for the .27 kernel http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-06/msg10114.html ....aufs2 needed too?

Aufs2 ok
Username: BarryK
"technosaurus, Official Aufs2 patch for 2.6.27 was available right up until late September, then the author decided to move up, and I [i]think[/i] now the minimum supported is 2.6.30. I downloaded the last patch that works on the 2.6.27 kernel, and it will continue to be available from the aufs download site.

Tags: puppy