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."

Comments

To infinity, and beyond!

[Dirtside]

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.?

Re:To infinity, and beyond!

[Christopher Thomas]

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?

Finishing moving disk-related parameters to 64 bits makes this largely unnecessary. It is extremely unlikely that we'll have to worry about devices with more than 2^63 blocks for a very long time (with 1k blocks, this would be eight [us] billion terabytes).

Having the OS scale block size instead of just using a sane parameter width leads to much nastiness (remember how much fun FAT16 was).

Re:To infinity, and beyond!

[bruthasj]

> for a very long time

Let's compute this long time, just for fun. Let's see, we've got to assume a bunch of crap before we can compute a specific time for this. Using data from this and this, let's assume that the current largest hard drive size on the market is 180GB with a doubling rate now at 9 months. (The 80s saw 30% growth annually, 60% in the 90s and 130% now.) Unlike processors, which have been steadily doubling every 18 months thanks to Mr. Moore, it appears that the growth rate itself for storage capacity is doubling every 10 years. Go figure.

Let's use this, blow some hot air and molest these numbers a little bit.

180 * 2 ^ p = 8 billion TB

p = periods of doubling = 36

Using a flat constant growth of 130% this would equal to

36 * 9 = 324 months / 12 = 27 years

Now, we see crossed 2 periods of doubling in growth, but can storage technology really experience growths of 260% or 520% annually. I'd have to say not, so I'll just give up computing the time given the growth of the growth right now. That's an assignment left to the reader -- I'd say it has to do with "e".

Anyhow, the reality is:

1) No one will ever read this comment since the article is so far down on the front page.
2) We'll have quantum computers in 10 years that will use unlimited-bit numbers to access unlimited capacity storage devices.

Ok, I'm all babbled out...

Serial ATA support - why?

[yem]

From the TODO:

Would be nice to have before feature freeze, but most likely 2.7:
...
o Serial ATA support

From serialata.org:

Q13: When does Microsoft plan to support Serial ATA in its OS's?
A13: Serial ATA is software compatible with Parallel ATA and requires no changes to Microsoft operating systems, or any other OS as well.

If this is a drop in replacement for parallel ATA, why is support needed in the linux kernel?

mounting floppies, CD's and DVD's

[oever]

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.

Re:mounting floppies, CD's and DVD's

[yobbo]

supermount is entirely adequate, IMO. Sure there may be dangers removing floppies, but then again, do we *really* need floppies still? I thought we were over the days where we'd save our documents to 8 different disks and hope one of them worked when we got to work...

Re:mounting floppies, CD's and DVD's

[rossz]

The need to mount and unmount CD/DVDs has been one of my pet peeves. Hell, Windoze can detect when a new disk is inserted and even launch stuff (which is annoying but can be disabled). So use the same technique and automount the damn thing. And when the eject button is pressed, catch that and umount. If the Microsoft programmers can do it, it can't be all that hard!

Re:mounting floppies, CD's and DVD's

[DGolden]

I find a deeper problem with removable disks on Linux and Windows: ranted about this at length on LKML a while back. I'm now trying to do something (possibly misguided) about it. The basic problem is that a disk is not the drive it is in.

both Unix and Windows, in general, assume it is. You don't copy a file to "disk xyzzy", you copy it to "A:" or "the filesystem mounted on /dev/fd0" - /dev/fd0 identifies a drive, not a disk!

The amiga got this right:
a disk became part of the filesystem based on its label/id, if possible -
so I could say "copy mfile.doc to xyzzy:mydocs", and if the disk xyzzy was unvailable, the system would prompt for it, while the copy process blocked waiting for it. If I put it back in a different drive, the system didn't care.

I'm currently casting an eye over the linux block device and filesystem code with a view to mangling into something vaguely amiga-like - but I'm not really even a C programmer (more of a Lisp guy), so I make take a while.

Basically, a disk contains a set of blocks. Some or all of those blocks may be accesible via a block device file. But you should be able to mount the filesystem "on the set of blocks of the disk", not the set of blocks currently accessible by a particular drive - disk partitioning schemes still have one or two fields to facilitate this, the disk label/name and/or a uniqueid.

If I have a disk labelled "peaches", I want it part of the filesystem at e.g. /mnt/peaches, and if I have two drives, I don't want to have to care about what drive it is in!

My project

[Alsee]

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.

-

are you new here?

[Xtifr]

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>

kbuild?

[spongman]

how about kbuild that has been ready for a fucking eon? yeah, yeah, it's a big patch, so were the first few that went into 2.5, and kbuild2.5 was ready then, too. and still we wait for kai to pretent he's helping...

politics: from the greek: poly:(adj.) many, ticks:(n., pl.) blood sucking animals.

Re:Support for mounting NTFS

[Zapdos]

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.