Weekly Edition
Return to the Kernel page
| |||||||||||||
Kernel release status
The current stable 2.6 kernel is 2.6.19, released by Linus on November 29.
Says Linus:
It's
one of those rare "perfect" kernels. So if it doesn't happen to compile
with your config (or it does compile, but then does unspeakable acts of
perversion with your pet dachshund), you can rest easy knowing that it's
all your own d*mn fault, and you should just fix your evil ways.
For those just tuning in, major user-visible changes in 2.6.19 include the parallel ATA driver subsystem, the GFS2 and ext4 filesystems, a long list of new drivers, eCryptfs, and more. See the LWN kernel API page for a list of internal API changes, and the KernelNewbies 2.6.19 page for vast amounts of detail. The current -mm tree is 2.6.19-rc6-mm2. Recent changes to -mm include some driver core tweaks, suspend/resume support for a number of parallel ATA drivers, the file capabilities patch (see below), and a per-task I/O accounting feature. For older 2.6 kernels: the current 2.6.18 kernel is 2.6.18.4, released on November 29. It contains a single fix for a buffer overflow in the network bridging code. For 2.6.16 users, Adrian Bunk has released 2.6.16.33 and 2.6.16.34 with a number of fixes and (in .34) a few new drivers. (Log in to post comments)
Time to switch to a "pure SCSI" system Posted Nov 30, 2006 2:15 UTC (Thu) by proski (subscriber, #104) [Link] To switch to the PATA, make sure you mount all filesystems by label or UUID. Even FAT filesystems can be mounted by labels, but keep in mind that they will always be uppercase. Swap partitions can have labels too, but I don't know if it can be set while in use, so turn the swap off and use "mkswap -L LABEL" on the partition.Check /etc/fstab and the bootloader configuration (especially the "root" option) and make sure no hard drivers are referred to by the /dev/hd* names. Make sure the system still boots and mounts everything correctly. Now you can try the PATA enabled kernel. If it doesn't work well, you can always go back. Once the PATA enabled kernel boots properly, you can make final adjustments, such as all remaining references to /dev/hd* under /boot, links to the CD-ROM devices in ~/.wine/dosdevices and whatever else you can think of. When referring to the hard drive partitions, you can use links under /dev/disk/by-label created by udev. You still can go back to the IDE kernels. They would boot even if those adjustments are not reverted.
Time to switch to a "pure SCSI" system Posted Nov 30, 2006 5:43 UTC (Thu) by thedevil (subscriber, #32913) [Link] "Even FAT filesystems can be mounted by labels"
Since when is this the case? I don't think it works for me, that's why I still use mtools (of all things) to transfer pics from my camera flash. Also, what of ATA CD-ROM drives? Can't mount those by label, can you? Or do you have an entry in fstab for each CD-ROM you own? :-)
(I don't use udev, so maybe we're talking apples and oranges.)
Time to switch to a "pure SCSI" system Posted Nov 30, 2006 15:39 UTC (Thu) by drag (subscriber, #31333) [Link] If you haven't used Udev for things it is worth checking out.
Nowadays the traditional /dev/sda or /dev/hda style naming is convience only. There is no reason (aside from clueless applications) why you need to follow that.
For instance I wanted to use a Debian install on a flash key on as many computers as possible. Just a sort of 'see how well it works' type thing.
Well as you know flash devices will show up as /dev/sd* stuff normally. However going from computer to computer I would run into situations were they have a onboard SATA controller or maybe other flash devices and that the /dev/sd* name would change periodicly... Obviously not something that was compatable.
Then the 'obvious' solution was to use UUID labels to point at it, but since the UUID stuff was just symbolic links pointing at the /dev/sd* device (udev you can only have one 'real' device file for each device, but can have muliple symbolic links setup in the rules) on very rare occasions it would switch around differently from the initrd vs /root so that caused weird issues.
The real solution for me was to create a udev rule based on the make and model stuff for my flash drive. It would create it's own /dev/flashdrive, and /dev/flashdrive1, /dev/flashdrive2 for the drive and it's partitions.
This worked well.
Another situation was that there was a guy posts I read were he had various iSCSI drives that would show up as /dev/sd*. Well as the system booted and such these things would be detected in different order or all of them would not be immediately aviable so he had to make persistant naming for them using custom udev rules.
So he made the /dev/sd* stuff persistant, but realy I thought he should of made the udev rules make device files names based on more usefull information, like the file system label or what system they are coming from or something like that. That way it would make remembering the names and such for scripts easier.
Other situations were udev is very good is for stuff like hotplugging input devices. For instance I have a track ball, a joystick, a wireless mouse, and a wacom pad. Now using just the regular old /dev/input/* names it's a nightmare to keep these things configured correctly. All that can change based on which order I plug them in after a reboot and it can change based on what kernel I am using and stuff like that.
Then for my laptop I may want to plug in my Wacom tablet. Now I can't use the trick to just point the X.org at /dev/input/mice, because the trackpad has special configurations for speed and other features, while the wacom pad requires having special drivers for it's Xinput extensions for sensitivity to pressure settings then every time I want to use it I pretty much would have to log out of X, and log back in to have it go into effect.
When X.org gets support for hal/dbus/udev it will make these things much easier...
Traditional /dev/ static naming or devfs is ok for machines that have realtively static hardware configurations, but in a modern machine almost anything can change at any time and it's important not to have to go back into windows 95-land were I have to restart X every time something changes.
Other situations were it would be usefull is for things like you have a print server with many multiple printer devices and such.
Now for CDROM drives and such you could, if you wanted, probably do it based on file system for special disks or whatnot, but you'd probably write the rule based on the drive information itself.
Also there is some neat stuff you can do..
Like for instance you can set it up so that when you plug in a certain specific external drive it will execute a script to automaticly mount it, and rsync your /home directory, then unmount it.
Or maybe you have a laptop or whatever you could set it up to run a script whenever you plug your cardbus wireless adapter in and such.
Or you can write a script that will run a script to identify or setup the hardware to your specific purposes then setup names based on that.
If your curious check out:
It'll show you different strings and such. So if you realy realy wanted to you can probably do your sceme were you setup specific mount points based on the cdrom label name.
Time to switch to a "pure SCSI" system Posted Nov 30, 2006 9:27 UTC (Thu) by job (guest, #670) [Link] Just what I was thinking. Suddenly renumbering your hard disks will create a booting problem for a lot of users. I would have expected a big warning sign slapped on to this release.
Time to switch to a "pure SCSI" system Posted Nov 30, 2006 18:14 UTC (Thu) by nix (subscriber, #2304) [Link] The old ide subsystem still exists, with all the drives numbered as you'dexpect. Nothing changes unless you ask it to by asking to use libata instead. (Personally, my / is on LVM on every machine, so this won't affect me in the least; but I can see how it might burn some people.)
The new file systems: Posted Nov 30, 2006 9:34 UTC (Thu) by job (guest, #670) [Link] I know a lot of people prefer OCFS2 to GFS, because of the simpler, more "Linux-like" design. Is this still the case with GFS2? I would like to request an LWN article with in depth comparisons of the two, for all our exciting cluster needs.
When I'm at it (wishful thinking, that is), I would also like the ext4 developers to at least consider tail packing! That and the directory hashing has always been the greatest functionality of ReiserFS, especially for all those spool directories and maildirs.
The new file systems: Posted Nov 30, 2006 10:22 UTC (Thu) by mingo (subscriber, #31122) [Link] I know a lot of people prefer OCFS2 to GFS, because of the simpler, more "Linux-like" design. Is this still the case with GFS2? I would like to request an LWN article with in depth comparisons of the two, for all our exciting cluster needs.Here's the linecount of both of them:
GFS2: 26954 lines of code
+DLM: 11939 lines of code (generic lock manager)
= 38893 lines of code
ocfs2: 44952 lines of code (integrated lock manager)
So in that metric, GFS2 is simpler. It has also been cleaned up significantly and the code is very much "Linux-like".
In any case, more in-upstream-kernel filesystem competition is good and Linux can only win as a result :-)
The new file systems: Posted Nov 30, 2006 18:04 UTC (Thu) by bronson (subscriber, #4806) [Link] Just thinking idly here... I'd also be very happy if ext4 did tail packing. That said, I'd also like a flag that turns off all possible optimizations, reducing the amount of code that runs to a bare minimum. My mail spool is an example of a high-use volume where I can tolerate a bug or two: mount it -o3. My sarbanes-oxley archive is big, dumb, and slow, but I need it to be TOTALLY stable: mount it -o0.
I'll second your desire to see a cluster filesystem article too. :)
The new file systems: Posted Nov 30, 2006 21:37 UTC (Thu) by proski (subscriber, #104) [Link] More options to choose from means less test coverage for every single combination of the options. I'd rather stick with the defaults.Safety of data is obtained through procedures, not through clever coding. Most data losses are caused by improper procedures (such as missing backups or security breaches) rather than by the filesystem software failures. Consider using well tested code as part of the procedure. I'm very interested in the precise timestamps, but they are not in 2.6.19 yet.
|
|||||||||||||