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

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.

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!