Slashdot Mirror

← Back to Stories (view on slashdot.org)

Kernel Hacker Keith Owens On kbuild 2.5, XFS, More

Posted by timothy on from the informative-stuff dept.

Jeremy Andrews writes: "Kerneltrap interviews Keith Owens this week, an experienced kernel hacker who has long contributed to the Linux kernel. His contributions include updating ksymoops and modutils, both of which he maintains. He also works on kbuild 2.5. Earlier, he built the original Integrated Kernel Debugging patch. He's also working on kdb and XFS. Check out the interview." Lots of good information in here about things to expect in 2.5.

77 comments

  1. 2.5 hurry up. by satanami69 · · Score: 1

    I just compiled 2.4.13 and reboot. Now I lost use of my keyboard. I wonder if 2.5 will do that.

    --
    I really hate Dan Patrick.
    1. Re:2.5 hurry up. by tweakt · · Score: 1

      Perhaps you chose the wrong kernel configuration, left out USB keyboard support perhaps? Don't blame the kernel for your inability to configure your system. Besides... 2.5 with be a DEVELOPMENT branch... less stable, not more so. Think before you post.

  2. The Welsh Problem in the UK by euroderf · · Score: 0, Flamebait
    There is a problem with Linux development in the UK: it is dominated by the Welsh. Viz.


    Alan Cox - Welsh

    Keith Owens - Welsh

    Davedd Williams - Welsh

    Rhiannon Wemys - Welsh


    These are the big names of Linux development in the UK, there are very few Englishmen or Scotsmen who are big name Linux developers.


    The reasons for this are manifold. Firstly, Wales is a country long since colonised and dominated by England, the first acts of genocide were committed there. The Welsh have a strong and tribal identity, and are usually fairly open to new paradigms (hence their role in the Industrial Revolution, and OSS is at least as significant as the Industrial Revolution).


    This means that they have seized on Linux as a revolutionary operating system that may free them from domination by Microsoft and England. The welsh terrorist organisation, Plyde Cymru, uses Linux, it can be seen that they favour the decentralised nature of linux just like they favoured Owain Gln Dour's guerrilla tactics, which were similarly decentralised.


    Keith Owens is very much a Welsh nationalist and has criticised England many times, not least when I met him in a pub in Cardiff once, he broadsided against the oppressors (Sorry Keith :-).


    I think Linux does have a role to play in revolutionary freedom movements, and the Welsh Situation may make a good testing ground for this, especially around Trethomas.

    1. Re:The Welsh Problem in the UK by Anonymous Coward · · Score: 0

      > The welsh terrorist organisation, Plyde Cymru.

      Since when did PLAID CYMRU become a terrorist organisation.

    2. Re:The Welsh Problem in the UK by abl2002 · · Score: 1

      1. It's Plaid Cymru. 2. They're not a terrorist group. They're a mainstream political party. In fact they're the one mainstream party in the UK calling for an end to the bombing of Afghanistan! Calling them a terrorist group is extremely libellous and I suggest you post an apology. 3. The Welsh nationalists are hardly a great revolutionary freedom movement. In a recent referendum 49% of the Welsh voted _against_ a national assembly! 4. How, exactly, are the Welsh being 'oppressed' pray tell?

  3. XFS is pretty stable.... by SquierStrat · · Score: 1

    Going from the feel of my butt, not from benchmarks, XFS has been pretty stable on my desktop machine...however i've been experimenting with JFS, ReiserFS and currently ext3 and so far (remember no benchmarks) XFS seems the slowest of the 4 :-( Reiser or JFS seem to be the faster 2. None the less, when i get my new cisco dsl router and 24 port bay networks 24 port switch in and i turn my current router into a DNS/webcam/streaming mp3 server XFS will be my FS choice. Thank God for good coders! :-)

    --
    Derek Greene
  4. This is so cool by Anton+Anatopopov · · Score: 3, Interesting
    I have often wanted to have a go at kernel programming. I want to try and write some device drivers, but I am always too scared of this 'black art'. Its good to see someone taking time out to make it a bit more comprehensible for 'the rest of us'.

    I'm wondering, do kernel developers use tools like vmware/plex86 to debug their running kernels ? It seems like we've come a long way since debugging with strategically placed printfs

    1. Re:This is so cool by pe1rxq · · Score: 1

      First: they are strategically placed printks not printfs.
      And no they are still usefull, like Linus has said (and you know Linus is always right, don't you?) they force you to think about what you are doing before trying another run.

      Trust me nothing beets a bunch of printks and a serial console when debugging a kernel.

      Jeroen

      --
      Secure messaging: http://quickmsg.vreeken.net/
    2. Re:This is so cool by rasmus_a · · Score: 3, Informative

      > I have often wanted to have a go at kernel programming. I want to try and write some device drivers, but I am always
      >too scared of this 'black art'. Its good to see someone taking time out to make it a bit more comprehensible for 'the rest of us'.

      Try www.kernelnewbies.org. Esp. look in the book section for Linux Device Drivers v.2 and the online version.

      Wrt. debugging, prinks are still used alongside everything else. I do not think that debugging is done with vmware or plex86 yet but there is a port of the kernel to userland (User-Mode Linux) which is used by some.

      Rasmus

    3. Re:This is so cool by jdub! · · Score: 1

      Almost... :)

      Jeff Dike and User Mode Linux to the rescue.

    4. Re:This is so cool by SurfsUp · · Score: 3, Interesting

      I'm wondering, do kernel developers use tools like vmware/plex86 to debug their running kernels ? It seems like we've come a long way since debugging with strategically placed printfs

      Vmware or plex86 could possibly be of some use, except that they're no good for debugging device drivers since the real devices are hidden behind a virtualization layer. For non-device driver work User Mode Linux is a more lightweight solution, and tracks the latest development kernels much more closely. An increasing number of the core developers are using User Mode Linux regularly.

      For heavy debugging work on live kernels, kgdb is the perferred solution, with a serial cable link to a test machine. It takes a little more work to set this up and you need two machines. Kdb is a simpler debugger that can be patched into the kernel, useful for tracking down elusive kernel problems. It's included by default in SGI's XFS patch and pre-patched kernels.

      There are some great tools available including LTT, the Linux Trace Toolkit and various lock-monitoring patches. Unfortunately, most driver development is still being done by the printk/reboot method. If this is your preferred method, make sure you install a journalling filesystem unless you like spending most of your time watching fsck work.

      --
      Daniel

      --
      Life's a bitch but somebody's gotta do it.
    5. Re:This is so cool by Anonymous Coward · · Score: 0

      I thought Linus said "it puts hair on your chest", not "forces you to think about what you are doing"

  5. Grammar flame (sorry :) by kubrick · · Score: 1

    interview's Keith Owens

    There's no need for an apostrophe* in "interviews".

    * The superscript sign ( ' ) used to indicate the omission of a letter or letters from a word, the possessive case, or the plurals of numbers, letters, and abbreviations. (ex dictionary.com)

    --
    deus does not exist but if he does
    1. Re:Grammar flame (sorry :) by Bob+Ince · · Score: 1

      Don't be sorry. Putting an apostrophe in a third-person verb is a particularly dismal error, and deserves to be mocked without mercy.

      PS. help for idiots.

  6. Re:XFS is stable.... by Anonymous Coward · · Score: 0

    XFS does rock. Interesting to hear of Linus's objections about the kernel debugger. Can see both sides here.

    Can the debugger be made seperable, to keep the Chief happy? Have been using XFS on all home and a few production machines (once I proved I could recover from a bootable CD) with good luck. Performance is good, reboots guaranteed ) aside from rm -rf /usr/* :^(, but there is something about changing/deleting a big list of files.. (chown -R usr /usr/* etc) that bogs... Hope to see it as an option in 2.5 at least in the main kernel code! Darwinism is good.

  7. Re:Let me get this straight... by pe1rxq · · Score: 0, Offtopic

    All these terrible things happened and you have the gall to be ranting on slashdot???????

    --
    Secure messaging: http://quickmsg.vreeken.net/
  8. Broken Link by tweakt · · Score: 1

    You need to fix the link to kbuild on sourceforge. =)

    1. Re:Broken Link by tweakt · · Score: 1

      Hmm, on second thought... MOST of those things are broken. They all have "target=new" at the end... you guys really need to proofread this stuff.

  9. Silly troll, by tweakt · · Score: 0, Offtopic

    slashdot's for INTELLIGENT people. Now go back to your hole.

  10. Re:Let me get this straight... by Anonymous Coward · · Score: 0

    I bet we'll still get one of those trolls in 5 years. That is, if /. is still there.

  11. I wonder will they incorporate ACPI by RayChuang · · Score: 2

    I wonder will the Linux kernel writers seriously look at incorporating support for the Advanced Configuration and Power Interface (ACPI) for the 2.5 kernel test release.

    This could be very significant since ACPI allows for highly-automated system configuration, which is necessary if you want seamless hot-docking of external devices and ease of system upgrades.

    --
    Raymond in Mountain View, CA
    1. Re:I wonder will they incorporate ACPI by ogesII · · Score: 1

      yes, although nothing is in stone the hibernate and sleep mode will most likely be incorporated. by the time 2.5 is started ACPI will have already replaced APM in most systems. This should make supported systems the rule and not the rare exception they are today.

      http://content.techweb.com/wire/story/TWB2001040 4S 0002

      Here is a great article from the summit for more 2.5 info
      http://lwn.net/2001/features/KernelSummit/

    2. Re:I wonder will they incorporate ACPI by Anonymous Coward · · Score: 0

      Huh? there's already ACPI support in 2.4 - you just can't enable it at the same time as APM, for fairly obvious reasons. Distros always compile the kernel for APM, since that's what almost everything vcurrently uses, but if you compile you're own kernel, it's a matter of saying "Y" to ACPI.

    3. Re:I wonder will they incorporate ACPI by Anonymous Coward · · Score: 0

      People are working on it, but Linus and Alan Cox apparently hate ACPI and don't seem all that interested if it works or not. (Something to do with the kernel running untrusted binary code in the BIOS.) Instead, they'll probably replicate most of ACPI's functionality in the kernel.

    4. Re:I wonder will they incorporate ACPI by Steve+Hamlin · · Score: 1

      See http://lwn.net/2001/features/KernelSummit/ for fairly comprehensive list of changes planned on for 2.5.

      Third section up from the bottom is what they plan on doing for power management.

      Intel's ACPI implementation is out there now, and is being used by FreeBSD. They are currently waiting for the 2.5 fork to submit it for Linux. As a measure of the complexity of ACPI, consider that this implementation has "5-7 person years" of development work in it already, and does not yet have support for putting systems to sleep.

      So ACPI is important, despite its bulk. 2.4 already has the ACPI interpreter in it, but 2.5 will be where we see a truly working implementation of this standard.

    5. Re:I wonder will they incorporate ACPI by jquirke · · Score: 0

      The whole point of ACPI was to be a very flexible power management system, as well as a "configuration interface".

      Unlike APM (which was never properly documented and hence most BIOSes had unusual quirks/bugs resulting in bloated APM code in the kernel to try and handle all these problems), ACPI and the newer ACPI2.0 was thoroughly documented - see how big the specification document is. Unfortunately, for the ACPI 1.0 generation, it still seems so much hardware does not conform to the standard, and hence the power management mess is still around despite the good intentions of Intel & co.

      2.3 saw the introduction of a primitive ACPI 1.0 implementation, and 2.4 saw this evolve into a more useful implementation, complete with AML interpreter, as well as better integration with device drivers.

      Hopefully 2.5 shall see a *better* userspace interface, giving users more access to the true flexibility ACPI offers.

    6. Re:I wonder will they incorporate ACPI by Anonymous Coward · · Score: 0

      No, we leave ACPI to real operating systems, like Windows.

    7. Re:I wonder will they incorporate ACPI by Anonymous Coward · · Score: 0

      You are an idiot. In case you didn't know, ACPI is _mandatory_ on ia64. It's how you probe and attach devices.

      But that's ok, right? You don't need devices on an ia64! Hell, you linux guys don't even want an ia64 port at all, do you?!

  12. It's a shame about Linus's opinion on kdb by wowbagger · · Score: 3, Interesting

    While I can certainly understand Linus wanting to encourage would-be kernel developers to learn "a gram of analysis is worth a kilo of debugging", I do wish he would consider one area in which a kernel debugger is invaluable - hardware integration.

    "In theory, there is no difference between theory and practice. In practice, there is." In hardware development, there is the theory of what the hardware documentation says the chip will do, and then there is the practice of what it actually does. DMA's don't, interrupts stick, registers report old data. Obviously, you START by writing a user space app that pokes at the hardware (and this is one area in which Linux is head and shoulders above WinNT - there is NO way for a user space app to access hardware in NT, while in Linux you simply have to be root), but when you finally need to hook interrupts, allocate DMA buffers, etc., you need a debugger that can look at these events.

    Also, when porting to other CPUs, you sometimes need to see what is going on at the hardware level, and how it affects the drivers in the kernel.

    Yes, allowing debugging without analysis is bad. But throwing us back to the stone knives and bear skins era just to encourage hardier folks is an overreaction. Sure, make a KDB kernel bitch and moan during startup. Make it only allow root access, not normal user access. Force all file systems to run in full sync mode. But please don't make debugging buggy hardware any harder than it needs to be.

    (Now, if only AMD would add a JTAG debugger to the Athlon chip, I'd be a happy man.)

    --
    www.eFax.com are spammers
    1. Re:It's a shame about Linus's opinion on kdb by t · · Score: 1
      (Now, if only AMD would add a JTAG debugger to the Athlon chip, I'd be a happy man.)

      Have you ever used jtag? It's the buggiest thing I've ever seen. I've used it a lot on PPC and what they always fail to mention is that the jtag controller has to know what rev mask you're using on the chip. If anything is amiss, you'll get random operation.Not to mention the way it badly interacts with caches. And also that most board manufacturers fsck their jtag ports up. Did I also fail to mention that the damn jtag controllers cost like 5-8 grand? In the end all it does is restrict development to groups willing to lay down big money for the priviledge of developing for your system.

      t.

    2. Re:It's a shame about Linus's opinion on kdb by wowbagger · · Score: 1

      Your experiences are quite a bit different from mine. On all the DSPs that I've worked with, the JTAG debugger was around US$1K or less.

      True, the debugger program has to know what mask device you are working with, but that is usually a simple matter of selecting the correct mask when the debugger is launched.

      Perhaps you are thinking of a full JTAG implementation, with full scan chain support et cetera. I am talking about a simple implementation like Motorola's Background debugging mode support.

      Besides, if you thing JTAG is flaky, try using a bond-out pod. I've not seen bond-outs for CPUs faster than about 20MHz, and those were always "stand on one foot, hold tongue just right, think happy thoughts, and don't breath while debugging" affairs.

      --
      www.eFax.com are spammers
  13. Global Makefile! by swillden · · Score: 4, Insightful

    From the interview:

    ...kbuild 2.5 builds a global Makefile from Makefile.in fragments in each directory then compiles and links only the sections of code that absolutely need to be recompiled

    This is excellent, and I hope more open source projects start to go this way. It's been known for a while that recursive make is a bad idea because it's inaccurate. Naive recursive makefile structures tend to miss stuff that needs to be built/installed and fixing that problem (usually with ugly hacks like make dep) generally results in building stuff that doesn't need to be built.

    What Keith describes is a nice solution that provides the benefits of recursive make without the problems: Use per-directory makefile fragments which can be maintained locally, but automatically generate a complete, tree-wide makefile that is actually used for the build.

    There are tools other than make that provide more elegant solutions, but given that they never seem to catch on, I'm happy to see that someone is applying the tool we have (make) correctly, for once.

    I'm looking forward to this one.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    1. Re:Global Makefile! by slamb · · Score: 1

      Thanks for the link. It was very convincing. My library project will soon have a single global Makefile, once I get that idea working with the autoconf stuff already in place.

  14. that paper is weird by Anonymous Coward · · Score: 0

    I read the paper, and it seems to basically say "it's pretty hard to get your dependencies right with recursive makes. If you don't get your dependencies right, then bad things happen. Therefore, recursive make is bad." It certainly is possible, if you're willing to put in any sort of effort, to get correct dependencies with recursive makes. I'm not going to comment on which method is better or takes less work, but the paper misrepresents just how bad recursive makes are.

    1. Re:that paper is weird by SurfsUp · · Score: 2

      I read the paper, and it seems to basically say "it's pretty hard to get your dependencies right with recursive makes. If you don't get your dependencies right, then bad things happen. Therefore, recursive make is bad." It certainly is possible, if you're willing to put in any sort of effort, to get correct dependencies with recursive makes. I'm not going to comment on which method is better or takes less work, but the paper misrepresents just how bad recursive makes are.

      It's slow too.

      --
      Life's a bitch but somebody's gotta do it.
    2. Re:that paper is weird by swillden · · Score: 2

      I read the paper, and it seems to basically say "it's pretty hard to get your dependencies right with recursive makes.

      "Pretty hard" is an enormous understatement on large projects. When the project consists of thousands of source files it quickly becomes the case that *no one* knows what all of the dependencies are.

      The whole point of make is that the dependency management should be automatic. make is able to understand the full dependency tree all at once, if you allow it to. Multi-pass makes can solve that problem, but it's very hard to know how many passes are required and the process does get to be very slow.

      I'm not going to comment on which method is better or takes less work, but the paper misrepresents just how bad recursive makes are.

      I'll comment on it, and my experience is that you're dead wrong; for big projects recursive make is really bad. At one company I worked for a few years back I was the lead developer on a large Unix project. The build system was based on a recursive make that kept degrading over time. We'd give someone the task of fixing it occasionally, and they'd go off and spend a week or so getting it cleaned up, but within a couple of months it would be wrong again, and all of the developers were having to do frequent complete builds (which took five hours). Eventually we took to rebuilding nightly, and everyone got used to the idea that if your were working and stuff started to misbehave badly that you just had to come back the next day. I finally decided that the whole thing was costing us way too much in productivity, so I rewrote the build system myself.

      My goals were simple: I wanted a build system that (a) would do nothing if everything was up to date, (b) would not build anything more than once during a run and (c) would build correctly. Oh, and I wanted it to be easy to maintain. After three weeks of time I couldn't really afford to waste on a stupid build system I achieved my goals, but I had to write a shell script that checked a lot of the cross-module dependencies itself and directed the makes. Build times dropped from five hours to three hours and an up-to-date check took less than 10 minutes. I was very proud of myself.

      On the suggestion of one of the other engineers I decided to try a global makefile, using distributed fragments; it would be easy to construct and easy to maintain, but I was sure it would be too slow. Still, it only took three days to set up, so I tried it.

      To my surprise, an up-to-date check took 30 seconds the first time, and 5 seconds after that (because of file system caching). Overall, complete build times dropped to just over two hours. The makefile fragments were easy to maintain and the resulting build system was very robust. I disarded my other system, we switched to the global makefile and we never again had to waste days futzing with build processes.

      So I have no doubt about which is better and which takes less work. A global make is fast, trivial to build and maintain, and always works properly. Recursive makes are often very slow, require maintenance and sometimes screw up, which wastes lots of effort. The *only* advantage a recursive make has is that it makes local builds deep in the directory tree a few seconds faster. Even that advantage is nullified by adding a few extra targets to the global makefile fragments and specifying a build target on the command line.

      Recursive make is, simply, misuse of make. Tools are much more effective when used properly.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  15. XFS or Ext3? by Beowulf_Boy · · Score: 1

    I'm setting up a computer lab in my school using Redhat Linux. Its strictly for WEbsurfing, so I'm using IceWM and Netscape, which starts automatically, and I have an autologin script.
    I was using Redhat 7.1 with XFS, but now that Redhat 7.2 came out with Ext3, I'm considering switching, and re-ghosting the machines.
    Is Ext3 more stable than XFS?
    Is the Kernel that came with the SGI distro of Redhat 7.1 stable? Or should I switch to 7.2 with Ext3? Which would I be better off with in the long run? Which will run the longest? And survive the most power outages? (this is going in the 7-8th grade building).
    Thanks

    1. Re:XFS or Ext3? by izzertaq · · Score: 1

      If this machine is often powered off improperly, I would install ext3 on it rather than xfs. xfs has quite a few advantages over ext3, but "not losing data after hitting reset" is definitely not one of them.

      Basically, in ext3-speak, there are two kinds of metadata journaling. Writeback mode, supported by all the linux jfses, will guarantee that your directory and file structure is consistent after a hard crash, but it doesn't make any guarantees re: file data. This level of protection is about the same as ext2 + a really fast fsck on boot -- so you might see files with blocks from other files in reiserfs, for example. However, xfs is worse than that -- with its delayed allocation feature, you'll see entire files zeroed out after a crash. (See their mailing list archives for details.)

      ext3 supports this mode too, but the default is ordered mode, which forces stricter ordering on data writes. Data always goes to disk before file metadata is updated, so you'll either see the "right" data after a crash or the old data -- but never damaged data.

      AFAIK, ext3 is the only linux jfs with working ordered-mode support, though reiserfs apparently has patches in the works.

    2. Re:XFS or Ext3? by Anonymous Coward · · Score: 0

      Thank you for an informative post.

      This is just the information I needed to explain the weird things I was seeing after my system froze trying to unmount USB devices and having to press reset. I am using Reiser FS on Mandrake 8.1.

      Regards,
      Fred.

    3. Re:XFS or Ext3? by InsaneGeek · · Score: 2

      You are over exagerating some things here.

      The only way to guarantee that things do or don't get out to a drive is to run in a fully sync'd with the cache on the drive disabled. I do know that I can run in fully synchronous mode on XFS and I can guarantee that the write got out, but then your are throwing away all of your system cache and your system will be bogged to hell and back. Ext3 ordered mode is faster than XFS, Reiser, etc. because it essentially doesn't do journaling anymore (whereas the others, would write to the journal and then write the data out before the commit is done). When you really start to do any mildly heavy I/O this mode pukes over itself, since it requires all the data to get written to the drive before the transaction is considered commited. When you use either ordered or full data-journaled on ext3 you throw out all of your filesystem cache, and you better turn off the cache on your drive.

      A word of advice, *never* leave your drive cache on with ordered, turn off the power to the drive, and all those "supposedly commited writes that have been guaranteed to get out the drive are not there. Now you are completely screwed, you have to a *full* fsck of the entire fs, since ordered mode isn't journaled. If you are running in "data-journalling" mode on ext3 you do get the journal, and it still blocks the transaction until it gets written to disk, but it also has a journal meaning you get the 2 write hit just like XFS, Reiser, etc running in synchronous mode.

      So unless you are willing to take a performance hit ext3 gains you nothing over XFS, Reiser, JFS even then depending upon what you are doing it may be faster to run in full synchronous journal (on any one of them) with drive cache turned on making the ordered mode performance benefit nill. Any FS can guarantee that data will get out to the drive, I doubt any serious server will ever want to run that way. If you can safely assume that your system will stay up, ext3 performance in writeback sucks rocks compared to pretty much all the others. So the only benefit I see to ext3 (and admittedly it is a fairly significant one) is the ability to go from ext2 to ext3 without any data migration required.

    4. Re:XFS or Ext3? by Anonymous Coward · · Score: 0

      There was some discussion on Linux-Kernel that some|all IDE drives won't let the user disable the cache. Something to keep in mind if you are in a situation where data integrity matters.

    5. Re:XFS or Ext3? by Spy+Hunter · · Score: 2
      So the only benefit I see to ext3 (and admittedly it is a fairly significant one) is the ability to go from ext2 to ext3 without any data migration required.

      Is it really that hard to convert from ext2 to ReiserFS or XFS? I've never tried it.

      I just installed WinXP and converted my 10 GB FAT32 partition to NTFS. The conversion took about 2 reboots and 10 minutes. It was totally automatic, with no input necessary on my part. Is is that much harder to convert in Linux?

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    6. Re:XFS or Ext3? by Anonymous Coward · · Score: 0

      Correction: ext3 in ordered writes mode IS journaled. It only journals metadata in that mode (and obviously, in metadata only mode). Reiserfs and XFS also only journal metadata. ext3 has a full data journalling mode (which none of the others have) but no one uses it because its slow, and ordered writes mode gives you most of the same safety.

      Of course, this fact completely invalidates most of the info in your post, except for the warning to turn off your write cache on cheap-ass IDE drives that ignore the commit command. But that applies to any journalling filesystem.

    7. Re:XFS or Ext3? by InsaneGeek · · Score: 2

      Correction of your correction: XFS *does* have full data journaling, mount with option "wsync". It's called syncronous writes, and kills your performance just like it does with ext3.

      I was incorrect in stating that ext3 ordered mode is not journaled, but again due to the syncronous data writes; you have the same issue where you take a big performance hit due to the *long* amount of time it takes to have the disk spin to the place it needs to. Not only that, but you lose all the benefit of being able to stack multiple transactions together before it gets out to the drive (people are amazed at what command tag queueing can do), along with all the other benefits of letting the OS flush things out when needed.

    8. Re:XFS or Ext3? by Anonymous Coward · · Score: 0

      There is no conversion utility for XFS or ReiserFS. You have to copy the data from the ext2 partition to another partition, then mkfs the old partition to XFS or Reiser, then copy it back. If you're doing this to your primary partition, you'll need a boot disk that can handle the new FS.

      You CAN convert from ext2 to ext3 because the underlying FS is the same, they've just added the journal to it.

    9. Re:XFS or Ext3? by Spy+Hunter · · Score: 2

      Wow, that stinks. How come Microsoft could make a FAT32 to NTFS converter and no one can make an ext2 to XFS or ReiserFS converter?

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
  16. PRCS by shao · · Score: 1

    I am kind of interested about his words on PRCS.
    What exactly PRCS can do better than CVS in terms of maintaining multiple branches.

    Are there any known big open source project currently using PRCS?

  17. Re:Let me get this straight... by FreshFromTheCows · · Score: 0

    Of all the stupid things to do is be posting complaints on slashdot about people ranting on slashdot. Ok bud, good thinkin there...

  18. Another option soon - RH7.2 + XFS by Anonymous Coward · · Score: 0

    Yes, the rumors are true... soon there will be a RH7.2 XFS installer. Just to cloud your choices a bit more :)

  19. Slightly off topic by Anonymous Coward · · Score: 0

    I see some of his projects are being hosted at sourceforge. I have been hearing rumors this week that SourceForge is going the way of the dodo in the near future. Any truth to this?

    1. Re:Slightly off topic by holloway · · Score: 1

      Apparently not. The director of Sourceforge responded on Advogato about this rumour.

      --
      -Docvert converts MSWord to OpenDocument, clean HTML
  20. Signs u r a hard core geek :) by mbyte · · Score: 2

    ... u answer questions in a interview with links :)

    JA: Why does Linus refuse to include kdb?

    Keith Owens: http://www.lib.uaa.alaska.edu/linux-kernel/archive /2000-Week-36/0575.html

    JA: Why should it be included?

    Keith Owens: http://marc.theaimsgroup.com/?l=linux-kernel&m=968 65229622167&w=2

  21. Its not good by Bruj0 · · Score: 2, Insightful

    Linus is right, kernel debugers are not a good thing. You learn to fix the simptons no the dissease. If you want to code for the kernel you better learn it the hard way. ie. lots of hours rebooting and thinking what went wrong.
    But its a good thing that a kernel debuger exists, it will help you understand how it works inside. But WONT help you FIX things.

    bruj0-

    --
    http://securityportal.com.ar
    1. Re:Its not good by Anonymous Coward · · Score: 0

      I hope you're being sarcastic... If not, then you've never coded device drivers and don't realize the importance of the kernel debugger.

  22. KDB distinct from XFS by Anonymous Coward · · Score: 0

    Can the debugger be made seperable

    Absolutely, they're not the least bit entwined.

  23. ext3 by 42forty-two42 · · Score: 1

    BTW, anyone know where I can find an ext3 patch for 2.4.13? I'm also looking for the maestro3 module. They come with RedHat 7.2, but only on 2.4.9...

    1. Re:ext3 by fredlwm · · Score: 1

      here.

      --
      How to contact me - http://www.pervalidus.net/contact.html
    2. Re:ext3 by Anonymous Coward · · Score: 0

      dude, just rpm -Uvh kernel-2.4.9...

      the default 2.4.7 that shipped with RH 7.2 has some security vulnerabilities you really wanna get rid of

  24. What ? Born 1952 ? by Anonymous Coward · · Score: 0

    Hard to believe. He looks like 20.

  25. Re:Please stop offending people by Anonymous Coward · · Score: 0

    Why Troll ? Moderate it up you son of a bitch.

  26. Kernel now has Kernel debugger? by Tachys · · Score: 2

    I noticed that kernel 2.4.10 are later now have the selection kernel debugger, available under the kernel hacking. So does the kernel now have a kernel debugger

    1. Re:Kernel now has Kernel debugger? by Lennie · · Score: 1

      You probably didn't download a clean Linus kernel:
      www.kernel.org
      but you have something like a distributionkernel (RH/Mandrake/Suse/Debian/Slack/whatever it is)

      --
      New things are always on the horizon
    2. Re:Kernel now has Kernel debugger? by fredlwm · · Score: 1

      No.

      #
      # Kernel hacking
      #
      CONFIG_DEBUG_KERNEL=y
      # CONFIG_DEBUG_HIGHMEM is not set
      # CONFIG_DEBUG_SLAB is not set
      # CONFIG_DEBUG_IOVIRT is not set
      CONFIG_MAGIC_SYSRQ=y
      # CONFIG_DEBUG_SPINLOCK is not set
      # CONFIG_DEBUG_BUGVERBOSE is not set#

      --
      How to contact me - http://www.pervalidus.net/contact.html
    3. Re:Kernel now has Kernel debugger? by Anonymous Coward · · Score: 0

      Only if you patch it with XFS

  27. We believe you by Anonymous Coward · · Score: 0
    We believe anyone who gropes his butt to tell us about fs stability.


    Please don't demonstrate, we believe you.

    1. Re:We believe you by SquierStrat · · Score: 1

      That wasn't even funny. Pretty stupid in fact.

      --
      Derek Greene
  28. Re:XFS is stable.... by SquierStrat · · Score: 1

    Why is the above comment modded to zero? It's a relevant informational statement...

    --
    Derek Greene
  29. We switched back from ReiserFS to ext2... by parabyte · · Score: 2, Interesting
    ...after a series of filesystem corruption on four different Machines using different Versions of ReiserFS with many different Kernels from 2.4.2 to 2.4.12, with different SCSI disks as well as on several IDE drives, and systems ranging from a Dell Inspiron 8000 Notebook over some homegrown single PIII, dual PIII's on different Mobos to a Dell dual P4 Rambus system. For the last twenty years I have never seen something like this:

    After power cuts on frozen development systems it regularly happened that files written minutes ago were completely corrupted; they were there, but just garbage in them; what you have written explains what probably happened; however, it troubled me that files written minutes ago were affected. What really upset me to throw out ReiserFS on every machine was when after a crash every File I created within the last two hours was destroyed; I never thought a Filesystem might take out many hundred files with such a precision. Even if I would not blame ReiserFS for this disaster (I Do), I consider it as completely unacceptable that all this happened without the slightest warning; no entry in the syslog, no boot message, nothing. ReiserFS pretended everything is fine. Do you have any explanation for such an behaviour, and are such effects just the downside for using a journaling fs, or is it something ReiserFS specific ? What added to my loss of confidence into this ReiserFs was that a few months ago reiserfsck did core dump when I tried to repair a file system that showed strange behaviour, which I regarded as exceptional behavior at that time.

    For now I switched back to ext2 and feel pretty good to see a thorough filesystem check after a crash. I do not remember much trouble using XFS with IRIX, but I have no experience so far with any journaling fs on linux exept those mentioned above. So do You have any recommendation for a filesystem on a unstable development system, where I can not sacrifice too much performance, but need at least confidence into the integrity of my fs ? (I did not loose much data, but It easily takes a few hours to bring back a system from the backups, but an unnoticed damage to vital files can drive you crazy). p.

    --
    Without order, nothing can exist. Without chaos, nothing can be created.