Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Features For 2.5 Linux Kernel

Posted by michael on from the modprobe-autopr0n dept.

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

59 of 141 comments (clear)

  1. "An anonymous person writes" by orthogonal · · Score: 2, Funny

    Why's he "[A]n anonymous person" and not "an An Anonymous Coward"?

    Should I infer something about his identity from this? Should I infer that this means the /. editor knows this person's identity?

    Should I cue the X-Files theme song?

    --
    Opinions on the Twiddler2 hand-held keyboard?
  2. To infinity, and beyond! by Dirtside · · Score: 4, Interesting

    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
    1. Re:To infinity, and beyond! by Christopher+Thomas · · Score: 5, Insightful

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

    2. Re:To infinity, and beyond! by GroovBird · · Score: 2

      Yeah, and 32-bit is more than we'll ever need. Who can imagine 4GB of memory in a machine! We'll never need more than 32-bit in our processors!

      or...

      640KB is enough for everyone!

      see a pattern already?

      dave

    3. Re:To infinity, and beyond! by Anonymous Coward · · Score: 2, Informative

      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.

    4. Re:To infinity, and beyond! by Alsee · · Score: 2

      disk-related parameters to 64 bits makes this largely unnecessary

      Right.
      2^63 blocks ought to be enough for anybody.

      Grin, duck & run

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    5. Re:To infinity, and beyond! by Ami+Ganguli · · Score: 3, Insightful

      We may need it some day, but figure 64 gig (2^36) is a reasonable hard disk size today. Then assume that hard disk size doubles every year. We won't be running into the 64 bit limit for another (64-36=) 28 years!

      By that time all of our computers will be using 256 bit words, or maybe word-sizes won't really exist anymore. Who knows. Certainly Linux will have morphed into something entirely different. It's pointless trying to plan that far ahead.

      Also, there is in fact some limit to hard disk size, we just don't know what it will be yet. I have a 10gig drive in my laptop, and really I just fill it up with crap. I don't need half that much room. Until I start saving movies on my laptop I'll never need 80 gig. We'll run into physical limits too at some point.

      --
      It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
    6. Re:To infinity, and beyond! by Toraz+Chryx · · Score: 2

      That's a chipset limit, not a bios limit persay.

      (I think you were referring to the 512MB limit on i815E mainboards?)

    7. Re:To infinity, and beyond! by bruthasj · · Score: 5, Insightful

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

    8. Re:To infinity, and beyond! by Citizen+of+Earth · · Score: 3, Informative

      Keep in mind that there are only 10^80 (2^265) subatomic particles in the universe.

    9. Re:To infinity, and beyond! by Thing+1 · · Score: 2
      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.?

      I like this idea. Could be used for memory addressing as well, so you never run out of RAM.

      I see it working like this: use a 64-bit dword to store the address (or head/cylinder/sector/etc.). Only use 63 bits. When you run out of room, use the 64th bit to indicate that another 64-bit dword will be used along with the first (making it 126 bits of addressing, since the 64th bit of the second word would be used to denote a third 64-bit dword, which would give 192-3=189 bits, ad nauseum).

      We'd never run out of addresses, although there may be a performance hit once we start addressing really large amounts of data.

      --
      I feel fantastic, and I'm still alive.
  3. Serial ATA support - why? by yem · · Score: 5, Interesting

    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?

    --
    No, I did not read the f***ing article!
    1. Re:Serial ATA support - why? by MrResistor · · Score: 2

      Obviously, one can't write a driver for a cipset if one doesn't have the chipset. Either the manufacturers will provide Linux drivers, or we will have to wait until someone skilled gets a card and writes drivers for it themselves.

      That's the inherent problem with add-on cards.

      --
      Under capitalism man exploits man. Under communism it's the other way around.
  4. My Question: Why Does [s]locate Exist? by Nailer · · Score: 2

    Slocate indexes the contents of the disk. So does the MFT, FAT and whatever the Linux equivalent is called (I'm surprised I don't know this, but I don't).

    Would it be possible to organize that information in a manner so that it could be used to find / locat files in a very quick and efficent manner? I guess what I'm looking for is indexes which are updated on writes / unlinks. Would this be possible? Would there be drawbacks, and could they be counteracted? If someone with more skill than I implements this we'd all save a bit of time.

    1. Re:My Question: Why Does [s]locate Exist? by jrfonseca · · Score: 3, Informative

      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 .

    2. Re:My Question: Why Does [s]locate Exist? by Nailer · · Score: 2

      Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...

    3. Re:My Question: Why Does [s]locate Exist? by uchian · · Score: 2

      Thats for your post, but I still don't think that there any reason not to give a file a place in more than one location - a heirarchical tree and an alphabetic sort. I can't see it as being too expensive either - and you always exclude /var/tmp if you were worried about that kind of thing...

      Heres a quick way to compare the functionality of the file system structures versus locates database.

      let's say we want to search for documents on the computer.

      File system :

      find / | grep ".doc"

      Locate database :

      locate ".doc"

      Compare the speed. Locate is incredibly quick, especially on large harddisks.

      Now compare creating a new file in the file system :

      echo "hello" > test

      to updating the locate database so that it can find the file quickly :

      updatedb

      (I think you need to be root to perform this).

      Here the filesystem wins easily.

      Unfortunately, like most computer algorithms, there is no "perfect" solution to searching for and adding files : if you optimise for searching speed, then update speed suffers. If you optimise for access and updating, then searching suffers. You can optimise for both (by having both the file system and locate), but you have gained better performance at the penalty of storing the information twice and hence taking up more space and greater code complexity - you need the file system code and locate, rather than just one or the other.

      Another way to look at it : why does your favourate computer textbook, or a world atlas contain an index? I mean, that's just duplication of information already on the map!

      Of course, it's because it's easier to find the place you are looking for in the index, but the map is actually useful for figuring out how to get there...

    4. Re:My Question: Why Does [s]locate Exist? by Nailer · · Score: 2

      Sign, nobody's still answered the question. I assume it *is* possible, but nobody's been bothered. Obviously your comparison isn't very fair: you recreated the updatedb index from scratch, that would be unnecessary in the suggested system.

  5. mounting floppies, CD's and DVD's by oever · · Score: 5, Interesting

    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.
    1. Re:mounting floppies, CD's and DVD's by yobbo · · Score: 4, Insightful

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

    2. Re:mounting floppies, CD's and DVD's by yem · · Score: 3, Informative

      You probably want supermount. Just ask google.

      Here's a patch for 2.4.18:
      http://espectro.hypermart.net/supermount. patch

      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!
    3. Re:mounting floppies, CD's and DVD's by rossz · · Score: 4, Insightful

      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!

      --
      -- Will program for bandwidth
    4. Re:mounting floppies, CD's and DVD's by io333 · · Score: 2, Funny

      I keep trying to take the damn floppy drive out of the various systems I deal with, and I keep having some rediculous reason where I *need* to put the horror back in. It's bizzare. Try it: take a machine that hasn't had a floppy inserted into it in years. Remove the drive. It is a physical LAW that the machine will require the use of a floppy drive within three days.

      And my goodness: is there any brand of floppies left that doesn't have at least three dead in a box of 10?

    5. Re:mounting floppies, CD's and DVD's by WasterDave · · Score: 2

      is there any brand of floppies left that doesn't have at least three dead in a box of 10?

      No, there bloody isn't. I now maintain a small collection of antique floppy disks for the rare occasions where I want them to work.

      Dave

      --
      I write a blog now, you should be afraid.
    6. Re:mounting floppies, CD's and DVD's by rgbrenner · · Score: 2, Informative
      Its marked experimental because it has race conditions. Heres a quote from this LWN article:
      The most common answer to this problem seems to be supermount... There is also evidently a need for an audit by a serious filesystem hacker to deal with some questionable practices and race conditions.
      You can find more referencing to the race conditions in Supermount here.
    7. Re:mounting floppies, CD's and DVD's by DGolden · · Score: 5, Informative

      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!

      --
      Choice of masters is not freedom.
    8. Re:mounting floppies, CD's and DVD's by KjetilK · · Score: 2

      I just instructed my parents to mount and umount usnig the icons on KDEs desktop. Told them it is more secure and lessens the risk of data corruption. They are perfectly happy about it, it took them less than 5 minutes to master. Just go ahead and teach her.

      --
      Employee of Inrupt, Project Release Manager and Community Manager for Solid
    9. Re:mounting floppies, CD's and DVD's by Hawke · · Score: 2
      This isn't a full solution, but some "mount by label" stuff is already there.

      e2label /dev/foo "Foo"
      mount LABEL=Foo /mnt/foo

      Add in automounter magic, and TaDa: "Its a userspace problem," albeit one that assumes you are using ext2 as your only file system.

      If you actually want to hack this, look into the executable maps and wildcards features of autofs (man 5 autofs). It might be possible now with some clever automounter config files...

    10. Re:mounting floppies, CD's and DVD's by Hawke · · Score: 3, Informative
      oever says:
      Sure, I can use automount, but then its not safe to just remove the floppy.

      $ more /etc/auto.master
      # Format of this file:
      # mountpoint map options
      # For details of the format look at autofs(8).
      /misc /etc/auto.misc --timeout=1

      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.

    11. Re:mounting floppies, CD's and DVD's by Sloppy · · Score: 2
      It's not really a floppy issue; it's a removable writable media problem. There's Zip disks, etc. too to think about. (Yes, I still use Zip disks.)

      The problem has kind of been sidestepped by the popularity of CDR (and RW, and DVD, etc) drives which typically end up completely copping out by requiring a special application to write, instead of just being a filesystem. That really sucks, BTW, and it's even worse.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  6. Left Out and Left Behind by tarsi210 · · Score: 3, Informative
    Now, someone correct me, but it sounds like a lot of really really necessary crap is (probably) going to be left out of the 2.5 kernel (which will become 2.6 stable eventually). I'd like to mention a few here and why I'm stunned that they probably won't make it.
    • 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
    1. Re:Left Out and Left Behind by yem · · Score: 3
      * 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.

      Easy there - XFS has been available available for months for those that really want it. It'd be nice to have it in the base kernel, but its not like you're going without.

      I'd like to know exactly what hasn't been implemented in IPv6...

      --
      No, I did not read the f***ing article!
    2. Re:Left Out and Left Behind by RussGarrett · · Score: 3, Informative

      Full compliance with IPv6

      Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

    3. Re:Left Out and Left Behind by Ami+Ganguli · · Score: 3

      Depends on how you look at it. If the feature freeze holds (a big 'if') then 2.7/2.8 will follow in reasonable time. There's always a next version.

      The danger is that the feature freeze holds just well enough to keep a few important features out, but not well enough to bring a stable 2.6 quickly. That's pretty much the worst of both worlds.

      I'm hopeful anyway. I think everybody is serious about getting the release cycle shorter.

      --
      It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
    4. Re:Left Out and Left Behind by fferreres · · Score: 2

      # Reiserfs v4

      Will not be ready/tested. You can always patch your kernel to add support for it. It just won't come default as they can't bundle everything, specially the non stable developements (reiser4 has not even been released yet).

      # Full compliance with IPv6

      I am not an expect, but surelly the "full compliance" means a lot of unused parts that are non-critical and non-important and can be implemented later. For example, no C++ compiler implements all the C++ specs. Does this mean C++ is unsopported?

      # Serial ATA support

      What's this for?

      # Overhaul PCMCIA support

      I agree, it sucks a bit. I'd like it to be more userfriendly. I sometimes don't know what is used for what (what do you have to check to get ATA CompactFlash cards to mount?). Probably just my fault here! (the PCMCIA network card works great though, and Slackware 8 default kernel autodetected it).

      --
      unfinished: (adj.)
    5. Re:Left Out and Left Behind by RussGarrett · · Score: 2

      OK, so I jumped the gun a bit there - there are bits still missing from the Linux IPv6 stack which make it non-compliant, such as IPSec and such. See the USAGI project. But the major points of IPv6 certainly work on Linux.

    6. Re:Left Out and Left Behind by Screaming+Lunatic · · Score: 3, Informative
      Full compliance with IPv6

      Exactly what isn't compliant with IPv6 in the current (2.4) kernel? I'm currently using stock unpatched 2.4 to run a web server over IPv6 quite happily. It's the applications that are lacking support. Hell, with radvd it's functioning as a full 6-to-4 router for my home network.

      Here's a little info . Doesn't go into specifics. Follow the links and you end up here .

      They key is the "my home network" part. The router for an autonomous system would probably require full support. I'm running RH7.3 (kernel v2.4.18) and i don't see kame dancing.

    7. Re:Left Out and Left Behind by IamTheRealMike · · Score: 2
      # Reiserfs v4 - See the comment above about XFS.

      ReiserFS v4 makes some BIG changes to the kernel - for instance, it requires that files can be also directories at the same time. It's currently slated for December 31st, so I doubt it'll be in the next kernel. It's a big bit of work. Anyway, I think most distros have had ReiserFS v3 (which is also journalled) in their for ages, I know SuSE has, or you can recompile your own. Having it in the base kernel is nice, but hardly necessary.

    8. Re:Left Out and Left Behind by MrResistor · · Score: 2

      Serial ATA is software compatable with paralell ATA, so I hardly see a need to "add" support for it.

      If you mean Serial ATA add-on cards, well, people would have to have them and write drivers for them, or the manufacturers would have to write drivers. It's hardly reasonable to expect drivers that don't exist to be included in the kernel.

      --
      Under capitalism man exploits man. Under communism it's the other way around.
    9. Re:Left Out and Left Behind by tarsi210 · · Score: 2

      Oh, I agree with the shortening of the release cycle. My only point that I was trying to drive (and heck, it was late, maybe I wasn't clear enough) was that in software development, you have to balance the need to get the product out with the need to get the important features in. Although Linux isn't being "sold" to anyone, in a sense it is...to maintain corporate support and usage of Linux, the kernel has to maintain a software product's appeal, despite its free nature.

      To this end, I put on my corporate CTO's hat and looked at the listing of things being left out and said, "Uh...maybe a tad longer development cycle rather than shorter and getting a few more of the features in would be a good thing for the market."

      Mind you, I'm not a kernel hacker and therefore some of these issues I may have said, "Ok, why aren't these in?" and the reason is because they're involved beyond what I know.

      --
      Blog,Twitter
  7. Re:I see.. by MOMOCROME · · Score: 2, Insightful

    I think you might have it wrong...

    If what you were saying was the case, the writeup might appear more along the lines of ' ..feature freeze for the "2.5 kernel"...' instead of ' ..."feature freeze" for the 2.5 kernel...'.

    If you see what I am saying. The emphasis established by putting the phrase "feature freeze" in quotes is suggestive of that particular practice being unusual.

  8. Support for mounting NTFS by dytin · · Score: 2

    OK, I know, I'm stupid when it comes to knowing anything about the Linux kernel, so please be patient.

    I just got a new computer, and I installed a dual boot of Windows 2000 and Redhat 7.3. When I went into Linux, and tried to mount windows (mount /dev/hda1 /mnt/windows) an error was returned saying that the kernel did not support NTFS. Windows 2000 uses the NT file structure as oppoesed to FAT32 that previous versions of windows have used. My question is whether or not newer versions of the kernel will have the ability to mount windows 2000 partitions.

    1. Re:Support for mounting NTFS by UncleFluffy · · Score: 2

      They have been able to for ages. Looks like the default RH kernel isn't built with this enabled.

      --

      What would Lemmy do?

    2. Re:Support for mounting NTFS by philip_bailey · · Score: 2, Informative

      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 ~!
    3. Re:Support for mounting NTFS by Zapdos · · Score: 4, Informative

      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.
    4. Re:Support for mounting NTFS by gerardrj · · Score: 2

      Since Kernel 2.2 I think NTFS paritions have been supported as read-only.
      The stock kernel from your distro probably doesn't have the support comiled in. Assuming the kernel was compiled for loadable modules, you could compile the code as a module, and it would probably auto-insert itself when you tried to mount the partition.

      The HOW of getting that done isn't very difficult, but beyond the scope of this thread.

      --
      Article X: The powers not delegated... by the Constitution...are reserved...to the people
    5. Re:Support for mounting NTFS by UncleFluffy · · Score: 2

      I was aware that write support is extremely dubious, but I thought that read support was pretty safe - am I wrong ?

      --

      What would Lemmy do?

  9. My project by Alsee · · Score: 5, Funny

    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.
  10. are you new here? by Xtifr · · Score: 4, Funny

    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>

  11. kbuild? by spongman · · Score: 4, Interesting
    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.

  12. Re:Not a troll by fferreres · · Score: 2

    Evalhalla made an honest and insightfull reply. Your post has probably been maked "Stupid +1" if there was an option. Because of the lack of the option, they marked it a troll so that it doesn't expand automatically.

    Next version number will be 2.7/2.8 with 99,9% probability. Who cares?!

    --
    unfinished: (adj.)
  13. Re:Modversions... by fferreres · · Score: 2

    Apparently they don't like you to inset modules compiled for another differet kernel. The reson is not they like to make things harder, but that they think modversions is a mess and not the right solution (and it may cause more problems than it solves).

    I'd love to have some way to use generic modules but not sacrifice the stability of the system (as in insmod -f -error all arround-..."it works". And when the system freezes you don't know what it was (and when you bugreport, you translate the problem to the developers)).

    --
    unfinished: (adj.)
  14. In kernel checkpoint support? by maynard · · Score: 3, Interesting

    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

  15. So much for Enterprise Linux by baptiste · · Score: 3, Interesting
    While I understand that you have to draw the line somewhere and that it can be difficult to deal with such far flung development groups with their own priorities. BUT...

    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
  16. LSM to be included - yay! by sasha328 · · Score: 3, Insightful

    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

    1. Re:LSM to be included - yay! by AaronMB · · Score: 2, Informative

      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

  17. Re:my pet feature by autechre · · Score: 2


    Is that really what you want? If you're burning a CD, and you somehow hit the CD button by accident (let's say you have the DVD drive right above the CD-RW like I do, and you're trying to take out the DVD you left in there), do you really want the drive to immediately stop burning the CD and spit it out?

    There's a _reason_ the system won't give you back the CD "right now" sometimes. It's because it still needs it. You can handle waiting a few seconds for the program to finish reading data so that it doesn't block, explode, or fail at whatever it was trying to finish (which will probably lead to you being more upset than it not giving you back the CD the instant you want it).

    What sort of CDs do people use on a Linux system these days anyway, other than audio CDs (which don't need to be mounted)? And thankfully, some people are starting to get the idea that floppies are annoying and bad. True, they're now transferring files by emailing them to themselves via Hotmail...

    --
    WMBC freeform/independent online radio.
  18. Re:I see.. by FreeUser · · Score: 2

    If you see what I am saying. The emphasis established by putting the phrase "feature freeze" in quotes is suggestive of that particular practice being unusual.

    Which, historically, has been the case. Linus admits he isn't very good about things like that ... anyone else remember the "Give Linus a Backbone" website shortly before the release of 2.4?

    In any event, it is really unconscionable that XFS isn't being integrated into 2.5. It is hands down the best, most reliable filesystem under Linux bar none, and the only filesystem I will use on mission critical servers running Linux.

    This politicking about kernel patch sizes and "I don't like the way you tweaked [whatever]" has really gotten out of hand, and the result is that we have subpar filesystems integrated into the default kernel while the best of the breed remains an external patch.

    Maybe we'll get lucky and Linus will cave once again and let XFS through, but my money is on something a lot less innocuous, like another VM revamp in the middle of a "stable" series a la 2.4.

    --
    The Future of Human Evolution: Autonomy
  19. Why was UltraDMA requiring of new code? by Inoshiro · · Score: 2

    Because the hardware supports new features. You can use it in "dumb" mode, like you can run a 180gb Maxtor in PIO4 mode, but you're not getting your best use out of it (in this case, better speeds, cable detection, hotplug, etc).

    --
    --
    Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.