Kernel release status
Linus's pre-2.5.51 BitKeeper tree includes a new, generic compatibility layer for providing 32-bit system calls on 64-bit systems, an XFS update, some performance improvements from the -mm patchset, lots of fixes from the -ac tree, a number of module fixes (see below), better SCSI disk hotplugging support, and numerous other fixes and updates.
The current stable kernel is 2.4.20, which was released by Marcelo on November 28. The 2.4.20 patch is large - 21MB - and it touches almost 3500 files. Even so, it is mostly dedicated to fixes and updates, and generally making the stable kernel even more so. Those looking for new features will not be entirely disappointed, however; 2.4.20 includes new e1000 and eepro100 drivers, the JFS journaling filesystem, the new wireless API, the "block I/O from high memory" patch, the BeOS filesystem, the NAPI high-performance networking code, a number of VM tweaks, and support for the x86-64 architecture. It also includes, of course, the fix for the recent x86 denial of service vulnerability.
Unfortunately, 2.4.20 also contains a bug which can corrupt ext3 filesystems mounted with the data=journal option. This bug is described in this posting by Andrew Morton (but the included fix does not work and should not be applied). A real fix for the problem is still forthcoming; until then, be careful with data=journal.
Alan Cox has released 2.4.20-ac1, which adds a few fixes and a PA-RISC update to the 2.4.20 release.
For 2.2 users, Alan Cox has released 2.2.23. It
contains a number of fixes including, of course, the denial of service
patch.
Posted Dec 5, 2002 6:37 UTC (Thu)
by svachi (guest, #2177)
[Link] (3 responses)
Posted Dec 5, 2002 10:38 UTC (Thu)
by alspnost (guest, #2763)
[Link] (2 responses)
Anyway, Marcelo is doing a good job, but it's terribly ironic that so many recent 2.4 kernels have been released just before a critical bug / missing patch is discovered!
Posted Dec 5, 2002 11:33 UTC (Thu)
by Peter (guest, #1127)
[Link]
Also, the bug only affects file which have been written in the 30 seconds immediately prior to unmounting the fs. Perhaps wrapping /bin/umount with a shell script that first calls 'sync' might work around the problem.
Posted Dec 6, 2002 9:05 UTC (Fri)
by svachi (guest, #2177)
[Link]
Posted Dec 5, 2002 14:46 UTC (Thu)
by rknop (guest, #66)
[Link]
That is, unless there are other as-yet-undiscovered bugs in 2.4.20. -Rob
Thanks!! This article just saved my life!!2.4.20 ext3 bug
I was compiling 2.4.20 when I read about the
ext3 bug. Good timing!!
Most distros use data=ordered for ext3 though, so you shouldn't be bitten by the bug unless you've explicitly changed this.2.4.20 ext3 bug
2.4.20 ext3 bug
Most distros use data=ordered for ext3 though, so you shouldn't be bitten by the bug unless you've explicitly changed this.
I was using data=journal, just because I love changing things from default ;-)2.4.20 ext3 bug
Now I change back to data=ordered and installed 2.4.20 anyway.
Since I came from Windows, there is an urge in me to reboot machine from time
to time, so I need to find some excuses like kernel upgrade or something :-)
If the "mount" man page is to be believed, "data=ordered" is the default. So, unless you've explicitly put in data=journal, you should be OK.Kernel release status