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