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."
- 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
You probably want supermount. Just ask google.
. patch
Here's a patch for 2.4.18:
http://espectro.hypermart.net/supermount
The latest version of Mandrake Linux includes supermount and I've grown to like it. It would be nice to have it in the kernel, even if it was marked EXPERIMENTAL.
No, I did not read the f***ing article!
As a matter of fact, remember that the BIOS has a limit; you cannot aaddress more than 1024M of memory
on some PentiumIII motherboards, for example.
There has been some support for for the NTFS filesystem available for years. The original driver system is no longer developed, and a new system is being actively developed (link). Unfortunately, because of the complexity of this filesystem, which is not fully documented by Microsoft, only read support is satisfactory - i.e. it may be dangerous to write to an NTFS filesystem from Linux.
You may wish to explore loading NTFS as a module or compiling it into your kernel.
There is no place like ~!
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 .
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.
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.
/dev/fd0" - /dev/fd0 identifies a drive, not a disk!
/mnt/peaches, and if I have two drives, I don't want to have to care about what 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
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.
Choice of masters is not freedom.
well, if you are refering to ACLs in the filesystem, Extended Attributes has been in the VFS since 2.5.3 so now it's just up to the filesystems to include ACL information and the NFS server/clients to support the ACCESS command(there's a patch floating around to do it, but I haven't heard anyone talk about). Samba already supports ACLs if you are running XFS or Ext3+acl. If I can get filesystem/nfs-supported ACLs, i'll be happy.
-Aaron
Keep in mind that there are only 10^80 (2^265) subatomic particles in the universe.
$ more /etc/auto.master
/misc /etc/auto.misc --timeout=1
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
A 1 second delay good enough? There are still some details about remembering to change out of any automounted subdirectories, but this setup "Works For Me(TM)"
I also use the CD like this, and have setup some view profiles for Konqi that start in the directory. Now I can buttons on the desktop I click to look at the cd... and no need to care about mounting/unmounting it.