Slashdot Mirror
New Features For 2.5 Linux Kernel
An anonymous person writes "The current development version of the Linux kernel is 2.5. At the recent Linux kernel summit, it was agreed to have a "feature freeze" on this kernel by October 31, 2002. Here's a story looking at what's left to be merged before the freeze. Projects most likely to make it into 2.5 (and thus be a part of the next stable kernel, 2.6), include: the reverse mapping VM, the Linux Security Module framework, User Mode Linux and support for filesystems greater than 2TB."
So what I'm wondering is, wouldn't it be possible to invent a disk addressing scheme which basically self-extends, so that you would never really need to manually change things to support disk sizes beyond a certain size? In other words, depending on how big your hard drive is, the addressing method would change to address sectors of a certain size, keeping the need for indexes/tables/whatever down to a certain size, etc.?
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
From the TODO:
From serialata.org:
If this is a drop in replacement for parallel ATA, why is support needed in the linux kernel?
No, I did not read the f***ing article!
I'd like to install linux on my Mom's new computer, but the mounting of disks should be a lot easier. All we regular linux users are very accustomed to it, but really, it's rediculous.
It possible to jerk out my netword PC-Card. The network is closed down nicely. Reinsert the card and the network restarts.
But if I put a floppy in the drive, I cannot read it by default. Aargh. Sure, I can use automount, but then it's not safe to just remove the floppy.
And for the CD it's even more weird. A CD/DVD player has a button. This is disabled when I mount a CD. So a mounted CD cannot be ejected. Yet, mounting the CD when it is inserted. That's apparently asking too much.
It's great that so many new features go into the kernel. But why can't a simple feature like this make it into the kernel. There's no lack of patches.
DNA is the ultimate spaghetti code.
- Add XFS (A journaling filesystem from SGI) - Excuse-the-hell me? Isn't the idea to get journaling filesystems in to the kernel because that's what everyone wants? XFS is proven, get it the heck in there.
- Asynchronous IO (aio) support - This is really surprising in some ways. IIRC from the kernel summit summary, this was a hot topic and argued vehemently. Even Linus agreed it was a Good Thing(tm) and should be done. If I also remember correctly, it's a hell of a lot of work, so I can justify that.
- Full compliance with IPv6 - Ok, for crying in my lukewarm beer, this needs to get in there, folks. IPv6 needs to get going and you're not helping.
- ext2/ext3 large directory support: HTree index - Sounds like something that enterprise Linux people would enjoy, yes?
- Remove the 2TB block device limit - Ditto.
- Overhaul PCMCIA support - Ogg heat metal. Ogg form new stick from copper, copper much better than wood stick. Ogg progresses. Anyone else think that PCMCIA sucks under Linux? It could use an overhaul in a large, hairy, neanderthal way.
- Reiserfs v4 - See the comment above about XFS.
- Serial ATA support - I don't know how close this standard is to manufacturing, but it certainly sounds like this is the way that hardware is going (and bless them, too.) Probably a good thing to NOT leave in the dust.
That about does it for the ones that make me cringe uncomfortably. Past that, I can rationalize the other ones out. These just flick that, "Whoa, aren't you making a mistake?" light inside my head.And would anyone care to comment on the SCSI interface? According to the kernel summit, there was going to be much code yoinkage and redoing for the entire subsystem. Where does that play in the 2.5 freeze?
Blog,Twitter
support for filesystems greater than 2TB
Ah, good! This has been a major stumbling block for me. I've been writing a guide and I hit the 2TB ceiling. My target market is hitchhikers.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
The kernel developers know what a feature freeze is. There's no quotation marks around it in the referenced article. The quotation marks in the slashdot headline came from an "anonymous person" somewhere, and the slashdot "editors" decided to leave it there because they are "editors", not editors.
#include <usual lecture about reading the article before commenting.h>
Both alocate and the FS table index the content of a disk but with different purposes _and_ structures.
FS has a tree alike structure (which maps directly to the directories and files) to easily get from a file name to its position on the disk.
[s]locate has progressive encoding (from their website http://www.geekreview.org/slocate/) which maps from name fragments to their complete name.
Another difference is that slocate database structure is difficult to update, and you wouldn't want to do that everytime you rename/add/delete a file...
Note that I'm not an expert, and this is just my (incomplete and perhaps even wrong) understanding .
politics: from the greek: poly:(adj.) many, ticks:(n., pl.) blood sucking animals.
I'd really like to see one of the checkpoint patches includeded in the mainline kernel series. There are several to choose from: EPCKPT, CRAK, CP.... Which one doesn't matter (feature wise), they all basically allow for the kernel to stop a process, save it's state and pages to a file, and then load and restart that process by request.
Yes, I could distribute a patched kernel across all of my systems. But then I'm tied to that kernel until whichever project I'm following updates their patch (or I update it myself, and I don't consider myself competent as a kernel hacker). This would be a really useful mainline feature for those of us in the scientific computing community. Wasn't there some talk of one of these going in 2.6 proper? --M
Why is XFS still not considered ready? Its in almost every major distro except for RedHat. Heck - the XFS team even provides custom XFS RedHat installer iso's to fill in the gap. XFS v1.1 is already released and is being used on huge fileservers in production all the time. Why can't we get past the 'we don't like the way you tweaked module X' and finally move forward.
I wish EVMS was going to be ready - this is going to be huge for enterprises - finally a unified, feature rich storage manager.
LVM 2.0 - well, I'd rather ensure 1.x is super stable (it is so far for me) so this isn't as big a deal.
Serial ATA - Bummer. I realize this is new. But I get the feeling Serial ATA is going to be huge, especially for lower end servers. Finally getting real hot plug support and a setup that'll make things easier on the HW RAID vendors (I can't wait to see a Serial ATA card from 3-Ware!) I would hope this would be flagged as something to be merged into 2.6 as soon as its possible, even if marked experimental.
Don't get me wrong - I'm really psyched for 2.6, but there are some features (whose development is out of the control of the core kernel team) we really need, to push Linux farther and farther into the enterprise. I know you can patch in what you want - but many IT folks, even Linux zealots, are wary of doing so in production - they want stock RedHat kernels so they can tell their boss its gone through RedHat Q&A and all that. Its CYA sure, but necessary in many environments. Granted RedHat often adds stuff not in the stock kernel, but not usually hueg features.
Top Most Bizarre/Disturbing Error Messages
I think it is about time that the LSM (or anything similar) was included in the kernel. When it comes to access control, I think Windows NT/2000 wins hands down against Linux.
I know I am running the risk of being modded down for saying that Win2K is way ahead of linux (or other *nix for all I know) but in the real world of file sharing, we use permissions and auditing quite a lot; these are not always black and white (what linux is currently capable of) permissions, they are often varying shades of grey.
Hopefully, with LSM, this will change even if it is in the future (1 year? 2 years?)
For a good explanation of the LSM, read this from NSA/SELinux
3.2 How do I get Linux to understand NTFS?
There are two ways to get NTFS support. The simplest is to add the NTFS module to the kernel (as root):
modprobe ntfs
If this fails, modprobe: Can't locate module ntfs, then your distribution didn't install the NTFS module.
The second way is to recompile the kernel, yourself. This sounds like a lot of work, but it isn't that hard. Have a look at the section: How do I add NTFS support to Linux?
3.3 Can I write to an NTFS Volume, too?
NO.
There are two drivers, currently. The original driver, in 2.4 has some write code in it, but it is extremely dangerous to use it. The possibility of destroying your filesystem is very high.
The new driver, introduced in 2.5.11, has no write code at all. This may sound like a backwards step, but it was necessary to rewrite the driver in order to make the future coding simpler and more solid.
Adding write support will take a long time. NTFS is built like a database. Any changes you make, necessitate making changes in many places, for consistancy. Make a mistake and the filesystem will be damaged, make too many mistakes and the filesystem will be destroyed. Also, the current developers are only working on NTFS as a hobby, during their free time. If you'd like to help, please email: webmaster@flatcap.org.
Get a free ipod.