Slashdot Mirror

← Back to Stories (view on slashdot.org)

Reiser On ReiserFS's Future And More

Posted by timothy on from the salut dept.

Steven Haryanto writes: "This one's from Indonesia. InfoLinux did an email interview with Hans Reiser, in which he explained about the ReiserFS project plan and the new Namesys business model. Mr. Reiser told me that Namesys recently received $600K funding from DARPA to include encryption in ReiserFS v4.0." Dig this quote: "We are going to add plugins in our next major version, and we hope that plugins will do for filesystems what they did for Photoshop." Mmmm -- encrypted, compressed, journaling, extensible filesystems. Reiser also touches on issues of international software development and how programmers can achieve fame.

63 of 123 comments (clear)

  1. Correct URL by Anonymous Coward · · Score: 2
    White paper URL from the article seems wrong.

    http://www.namesys.com/whitepaper.html is much better.

    Cheers,

    --fred

  2. Solaris Journaled UFS? by emil · · Score: 2

    The most famous example of a file system that grew into journaling was Solaris UFS. I have heard some rather harsh criticism (from SGI) on the design. I don't know enough about filesystem design to discuss the merits, but I do know that Sun was the number one US server vendor last year, so they must be doing something right.

    Here is the man-page entry:

    logging | nologging

    If logging is specified, then logging is enabled for the duration of the mounted file system. Logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the file system. Once a transaction is stored, the transaction can be applied to the file system later. This prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck. And, because fsck can be bypassed, logging reduces the time required to reboot a system if it crashes, or after an unclean halt. The default behavior is nologging.

    The log is allocated from free blocks on the file system, and is sized approxima tely 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. Logging can be enabled on any UFS, including root (/). The log created by UFS logging is continu- ally flushed as it fills up. The log is totally flushed when the file system is unmounted or as a result of the lockfs -f command.

    1. Re:Solaris Journaled UFS? by Salamander · · Score: 2
      The most famous example of a file system that grew into journaling was Solaris UFS

      Perhaps I wasn't clear enough. I wasn't saying that you couldn't add journaling to an existing filesystem. What I was saying was that you couldn't add it *as a plugin*, i.e. by leaving the original code untouched and adding a separate journaling facility. You have to change the original code, at least to the point of making it "journal-friendly".

      UFS is a good example of this. They implemented a mostly-separate logging component called ufs_log, but the original code is still littered with flag checks and callouts to use it. It could probably be more modular than it is, which might be the source of SGI's criticism, but it could never be so modular as to be a plugin.

      --
      Slashdot - News for Herds. Stuff that Splatters.
  3. Re:I thought "crypto with a hole" was illegal? by Forge · · Score: 2

    RiserFS should fall under export restrictions since technically it's imported from Russia and other places. That's where most of Riser's staff works.
    --
    Quidquid latine dictum sit, altum viditur.
    Whatever is said in Latin sounds profound.

    --
    --= Isn't it surprising how badly I spell ?
  4. Re:Like Frank Xia ... by Forge · · Score: 2

    Or his uncle, Chow Yun Fat. Author of the original FAT file syustem.
    --
    Quidquid latine dictum sit, altum viditur.
    Whatever is said in Latin sounds profound.

    --
    --= Isn't it surprising how badly I spell ?
  5. Mmmm... CPU cycles by Lally+Singh · · Score: 5
    Mmmm -- encrypted, compressed, journaling, extensible filesystems.
    May ask for a moment of silence for the CPU? First IDE, now CPU heavy filesystems? Also, one of my first questions is, how do you compress a filesystem without having problems with either:
    • Making seeks tough to calculate, or worse, requiring many disk accesses to get the right address
    • Performance problems with things like writes in the middle of the file, causing the dictionary for that part of the file to overfill and the whole portion of the file to need recompression

    Perhaps I'm just not up on the latest compression techniques (most likely), but those questions just popped in my head.

    Either way, this is just further down the road of increasing CPU requirements just to drive the friggin disk. Ick. I miss SCSI.

    --

    --
    Care about electronic freedom? Consider donating to the EFF!
    1. Re:Mmmm... CPU cycles by DiSKiLLeR · · Score: 2

      Hrm...

      Dunno. NTFS Is a journalling filesystem and has had compression and encryption for years. Compression has been in NTFS for at least 6 years, perhaps quite a lot longer. (dunno if NT 3.51 had NTFS compression).

      I've found it works *great* and has no real performace impacts. (apart from serious fragmentation if you go and compress your whole drive at once. When that happens, just do a big defrag.)

      Nevertheless, with the cheapness of hdd's these days (they practically give away 40gb drives) filesystem compression is rather useless.

      I also see your points, how do seek()'s and things work? I dunno.

      D.

      --
      You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
    2. Re:Mmmm... CPU cycles by ChadN · · Score: 2
      You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.


      And since compression is deterministic, compressing wil do absolutely NOTHING to protect against a ciphertext-only attack, except reduce (slightly) the effectiveness of a "birthday attack". A 128-bit block cipher (such as AES) should be perfectly immune to such attacks. Ie. compression does NOT enhance security of the ciphertext, in any appreciable way, using a modern (ie. non-DES) cipher.

      --
      "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
    3. Re:Mmmm... CPU cycles by rgmoore · · Score: 2

      IMO, the real solution to this "problem" is to use intelligence in choosing how you use your file systems. If you are in an environment where performance is hyper-critical and you need to have rapid, accurate seeks, you just don't use a compressed file system. You only use it for file systems where that's not likely to be a problem. The whole advantage of a pluggable architecture is supposed to be that the various attributes like compression, encryption, etc. are optional, after all.

      Of course there's also some question about the practical utility of compressed file systems these days. In practice, we're already using compressed file systems by using compressed file formats of various types. The big files that are going to use up all of the hard drive space for desktop-class users are things like pictures, music, video clips, etc. But those files are already compressed using JPEG, MP3, MPEG, etc., so a compressed file system isn't really going to buy you a whole lot anyway. Doing things that way also has the huge advantage that you can use highly optimized compression algorithms for each different class of data, rather than a generic one that won't work as well. People working on larger, more powerful systems are less likely to be willing to pay the performance hit for compression.

      --

      There's no point in questioning authority if you aren't going to listen to the answers.

    4. Re:Mmmm... CPU cycles by peccary · · Score: 3

      A few more thoughts:

      CPUs cycles are getting cheaper than I/O and memory bandwidth, but this kind of thing makes it hard to do DMA.

      Random access to files is not particularly helped by using the "latest compression techniques", it's more a matter of how you design the filesystem.

      You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.

      Most files are not accessed randomly, and of those that are, most of the file is eventually accessed even if it is done non-sequentially.

      Most random accesses occur on pagesize boundaries. Even if you are accessing one single byte in the middle of the page, modern VM-integrated buffer caches will fetch the whole page to do it. So what you need is not the ability to seek to any random point in the middle of the file, but just to any page boundary. Much simpler. You can store tables of these things.

      If you write to the middle of the file and blow the compressibility of the data, then you punch out the page and relocate it on the disk. Sequential contiguity suffers, but heck, you weren't accessing this file sequentially anyway, so why are you complaining?

    5. Re:Mmmm... CPU cycles by rabtech · · Score: 3

      Microsoft solved these problems by splitting all compressed files into 64k chunks -- the compression is done, one 64k chunk at a time. When a file is read, it is decompressed. If only part of a file is written back to disk, a chunk is compressed. If it is too large to fit in the space previously occupied, it just finds a space on the volume large enough (estimated) to hold the rest of the file, and stores that chunk there. If one chunk must be relocated, it starts relocating all the rest of the chunks (two file fragments are better than 10.)

      Novell takes the scheduled approach -- files are always written uncompressed. Later, at a specified time, the system looks for "compressable" files and compresses them. In this way, only decompression is performed on the fly.
      -------
      -- russ

      "You want people to think logically? ACK! Turn in your UID, you traitor!"

      --
      Natural != (nontoxic || beneficial)
    6. Re:Mmmm... CPU cycles by Hater's+Leaving,+The · · Score: 4

      Very good post. You ask all the right questions.

      Compressed FSs have always had this problem. The best solution that people have comeup with is one that we have already implemented - caches.

      In particular, the hairy writing to disk stage (where the compressions and on-the-fly construction of dictionary etc. takes place) only needs to be done on file closure.

      For some files, such as those that are frequently opened for writing, it's perfectly possible to have backgrounded compression. Basically you don't compress the file until a later point in time, you store it uncompressed on the hard disk and mark it as such. It's a seperate house-keeping job to actually compress the files (when they are 'stable' for some heuristically defined stability function (e.g. closed >10 seconds ago, or yesterday, or whatever))

      Another helpful technique is to chunk the files, so that you only ever have to seek from the nearest chunk boundary. This simply shrinks the amount of data that suffers from the seek problem, and often (though _not_ always) reduces the compression ratio. (e.g. a large executable could possibly be made smaller, as the code and initialised data could end up in different chunks, and the compression model could only need to adapt to one type of data.)

      Note, however, that we are not talking about _a_ compression plug-in. We are talking about compression _plug-ins_ (i.e. plural). You can chose your plug-in depending on the requirements.
      e.g. A FS for infrequent writes and frequent whole-file reads, such as a document management server, and could use a 'slow' compression, fast decompression, no-seek algorithm.

      From purely personal opinion, I believe with current HD transfer rates giving the CPU the decompression task is a better than reading bigger files. However, I'd not swear to that until I've played around with it and tested it thoroughly, with all my favourite file types. (I tend to have 500MB highly-compressible log files from what I do, so this really pushed my buttons!)

      I do go on sometimes...
      THL.
      --

      --
      Keeping /. cynic density high since the fscking Kwhores/trolls arrived.
  6. Re:Standards, limits of extension interfaces by stripes · · Score: 2
    So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster ... however much faster is unknown, since this is totally untested.

    I don't see how it is x86 specific. It is specific to CPUs that use caches, which is pretty much all non-embedded CPUs, and many of the embedded ones. I would imagine this would not be faster on something like the Terra, which is a non-cached CPU, but since it relies on proper management of 1000s of hardware level threads, I don't think Linux is ready to run there at all. Even on those systems it should be faster then indirecting through a pointer, faster by exactly one memory access (the pointer).

    I do agree that it is untested (in terms of benchmarking). I don't think it has entirely wrecked extensibility. One needs to modify that file to add a filesystem, so you can't do it through a run-time loaded module...unless you use the generic void*.

    I'll go for "that is really really ugly", and maybe even "does that make a noticeable difference when you are probably going to schedule a disk I/O?", and even "I'm glad FreeBSD doesn't do that". There is no way I'll buy "it's x86 specific" though.

  7. Re:Standards, limits of extension interfaces by LunaticLeo · · Score: 2
    I think I gave up on the idea that Linux would ever know what it was doing with filesystems when I saw this abomination . That's right, Linux not only has no concept of vnodes, it actually uses a union of every single filesystem type for its inode data structure. Search lxr for "vnode" if you don't believe me. So much for generic, to say nothing of modular.

    This has been discussed on the LKML. Using a Union for all the various FS specific inode info is a performance hack. You could have a pointer there to a FS specific inode, but you are going to lose memory locality benefits, and cause cache line thrashing. Inodes are touch OFTEN, that makes thes memory issues important.

    Further this is a performance hack that takes advantage of the fact that the Linux Kernel is open source, and easily compiled. You can't get this advantage in closed source without arbitrary FS specific inode info size limits.

    But, you are right there is an ugliness to it, but don't make the mistake that Linux Kernel developers are idiots or poor coders. This has been considered.

    Remember the truism: The Perfect is the enemy of the Good.

    --
    -- I am not a fanatic, I am a true believer.
  8. Modular Plugins != plugin modules. by TBone · · Score: 3

    Just because something is modular in the kernel doesn't mean it can only be a module. The only case that this exists, AFAIK, is the protocol-specific masquerading modules.

    Maybe against the current recommendations, anything that I don't have to load as a module (my AWE32 and Masq mods) gets compiled into the kernel. Why? Because it's not like I won't need the features - that's why I selected them for compile in the first place.

    If you encrypt all of your main filesystems, then you'll just have a /boot partition with vmlinuz on it, and the encrypted filesystem mods already loaded. Load the kernel, find the encrypted root, and *Bam* there's your newly-readable filesystem. This isnt' rocket science.

    --

    This space for rent. Call 1-800-STEAK4U

  9. Ooops... by Psiren · · Score: 5

    What if you did something silly like placing your filesystem encryption module on your encrypted filesystem... Get outta that one Houdini ;)

    1. Re:Ooops... by Archie+Binnie · · Score: 2

      I just pray we don't get a Gaussian Blur plug-in, I like my data as it is.

    2. Re:Ooops... by dasunt · · Score: 2

      Off topic, but you reminded me of a bug I once saw on a page of "most interesting bugs" in an older version of multics. It seems that the entire OS was swappable, and in one version, the swapper-out module could swap out the swapper-in module...

  10. Re:encrypted, compressed, journaling.... by jimhill · · Score: 4

    (Wavy flashback lines)

    I remember when the Linux kernel introduced modules and in the race to out-module one another, a lot of newbies rebuilt their kernels with every single filesystem as a module. Ahh, those were the days...

    --
    Learn to spell: nickel, missile, lose, solely, amendment, speech, kernel, probably, ridiculous, deity, hierarchy, versus
  11. Re:Standards, limits of extension interfaces by scrytch · · Score: 2

    > Stackable vnodes, which are supposed to address this same need, are ancient history

    I think I gave up on the idea that Linux would ever know what it was doing with filesystems when I saw this abomination. That's right, Linux not only has no concept of vnodes, it actually uses a union of every single filesystem type for its inode data structure. Search lxr for "vnode" if you don't believe me. So much for generic, to say nothing of modular.
    --

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  12. Re:Standards, limits of extension interfaces by scrytch · · Score: 2

    > This has been discussed on the LKML. Using a Union for all the various FS specific inode info is a performance hack

    So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster ... however much faster is unknown, since this is totally untested.

    As for that truism, here's another: penny wise, pound foolish.
    --

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  13. Re:great news, xfs by Outland+Traveller · · Score: 3

    Not to start a filesystem war, but my experience with XFS on linux has been very positive. The install .iso is *polished*. The fs tools are plentiful and high quality. Performance is excellent. If XFS on MIPS is any guide, reliability is top notch too.

    I'm glad to see ReiserFS aggressively pushing the technology envelope, but I have nothing but good things to say about XFS, and would recommend it to anyone using a recent kernel who wants a robust journaling filesystem.

    As others have said I think there is room for both filesystems going forward.

  14. Re:Photoshop plugins? by sammy+baby · · Score: 2

    "Lens flare" - does nothing useful, but hey, you can't be a l33T web designer without it.

  15. Re:Plugins do the same as for photoshop? by Levine · · Score: 2

    How many plugins have you seen that fail (crash or fail to complete the operation) when you try them on a large image?

    Erm. None, really. Based on the architecture of the file system, I think plugins would be an interesting and, most importantly, plausible concept.

    No one wants to take a risk of widespread data corruption or data loss.

    You've obviously never seen the Linux zealots running the -dev releases of Debian. Sheesh! Talk about trashing a system sometimes... ;)

    Cheers,

    levine

  16. Plugins? by Webmonger · · Score: 2

    I suppose you could make "zipmagic for linux" (letting you treat .tar.gz files as directories). What else could you do?

  17. It's even easier than that... by GauteL · · Score: 2

    .. to make the same kind of mistake.

    I once in my very newbie-days made /etc a partition of its own.
    Too bad I needed /etc/fstab to mount /etc.

    1. Re:It's even easier than that... by jfunk · · Score: 2

      How about the time I accidentally did 'rpm -e rpm'?

      I find it very strange that nothing appears to depend on RPM in RedHat...

    2. Re:It's even easier than that... by jovlinger · · Score: 2

      I tried to manually upgrade libc (or whatever). So I rm-ed the symlink, and then tried to ln -s to the upgraded .x library. Unfortunately, ln (and a whole slew of other commands) are dynamically linked...

      That one took some juggling to solve. I now have a staticically linked ldconf.

  18. Standards, limits of extension interfaces by Salamander · · Score: 2

    I really hope that when Hans and Co. think about how to extend filesystems they'll put their weight behind some generic facility and not just pull some new ReiserFS-specific interface out of their collective ass. Stackable vnodes, which are supposed to address this same need, are ancient history. NT has had filter drivers - not just for filesystems but for just about anything - since day one, and they have proven invaluable as a way to implement new functionality without writing a whole new filesystem. Erez Zadok has done some really cool work on a system called FIST for this sort of thing. All of these should serve as sources of inspiration at the very least, and of code in some cases.

    On a different note, journaling is not really something that can be added as a plugin, extension, or filter. Even if you have a generic journaling interface or layer separate from the "core" filesystem code, you have to make sure that that core code is "journaling-friendly". This involves thinking about ordering and atomicity, plus callouts and hooks between the main FS and the journaling code. It's pretty pervasive, and not something that can be done "stealthily" by adding a plugin or filter to a filesystem that was never designed (or, as in ext3, redesigned) with journaling in mind. Encryption, compression, virtual namespaces, all sorts of other things can be added as plugins or filters, but not journaling.

    --
    Slashdot - News for Herds. Stuff that Splatters.
  19. Re:First things first... by SpinyNorman · · Score: 2

    I've had my /usr and /home partitions on ReiserFS for a long time, and had zero trouble with them (Mandrake 7.1 came with ReiserFS integrated into the 2.2 kernel).

  20. Different model by wiredog · · Score: 2

    The model of Red Hat, Caldera, et. al. isn't selling software. It's selling support. Many years ago (15-20) Jerry Pournelle, writing in Byte, said that in the future (today) money wouldn't be made from selling software, it would be made by selling support and documentation. Certainly there are many companies that already make money from all or part of this model. They also provide support for open source developement.

    --

    Best Slashdot Co
  21. DARPA by wiredog · · Score: 3
    $600K funding from DARPA to include encryption

    Nice to see that DARPA (the Defense Advanced Research Projects Agency) is still funding useful things like this. Remember that they funded the internet when it first started. They're usually up to something interesting.

    --

    Best Slashdot Co
    1. Re:DARPA by Laplace · · Score: 3

      Welcome to DARPA, where Research is our middle name.

      --
      The middle mind speaks!
  22. SQL crippling? by davidsheckler · · Score: 3

    Hans said:
    "SQL has been crippling the database industry for decades"

    I'll admit it's not the best syntax to manipulate
    a database but before SQL there was no uniformity
    in database access. At least you don't have to
    learn a new "language" for each database you
    maintain/access. I don't see how it's crippling.

    I am curious about any solution he would propose.

    1. Re:SQL crippling? by SuiteSisterMary · · Score: 2

      The good thing about SQL, as you point out, is that it's a common language that can be applied to any database. The bad thing about SQL is that, as you point out, it's a common languate that can be applied to any database, and therefore, as soon as your database wants to do anything that SQL doesn't already cover, you need to start creating extentions, and suddenly it's no longer cross-product.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
    2. Re:SQL crippling? by Lozzer · · Score: 2

      try Database Debunkings for some views of the limitations of SQL.

      --
      Special Relativity: The person in the other queue thinks yours is moving faster.
  23. Re:ROTFL! by jovlinger · · Score: 2

    the pedant notes that when going whoring, getting screwed and getting out ok are not mutually exclusive.

  24. LinuxTag by mindriot · · Score: 3

    Hans Reiser is also going to speak at LinuxTag 2001 in Stuttgart, Germany. From the LinuxTag website:

    What new features are planned for V4? Dancing trees to replace balanced trees, plugins, item handlers, ACLs, extents, a repacker, and more. Hans Reiser will discuss these plans with the audience, and get user feedback on them.
  25. Is it even legal for DARPA to fund GPLed code? by Brett+Glass · · Score: 3
    As I recall, Federal law states that work created by or for the US government is not covered by copyright. Therefore, the code would not be able to be GPLed, because the GPL requires a copyright!

    GPLing the code is also bad policy because people should be able to use technology that's developed with their tax dollars for any purpose. The GPL prevents enterprising programmers from using the code in their own products and making money from those products. It therefore seems to me that DARPA should either NOT fund such a project or insist that the code that is generated be placed in the public domain -- or at least licensed under the BSD License or the MIT license. After all, it's our tax dollars.... None of us should be denied the use of the code.

    --Brett Glass

  26. Re:I thought "crypto with a hole" was illegal? by Tungz10 · · Score: 2

    The export restrictions on cryptography have been lifted.

  27. Re:Plugins do the same as for photoshop? by stilwebm · · Score: 2

    Yes, the crashing of the plugins is because of bad programming. Exactly my point.

  28. Plugins do the same as for photoshop? by stilwebm · · Score: 4

    While the plugins for Photoshop are great and very powerful, there is one problem. How many plugins have you seen that fail (crash or fail to complete the operation) when you try them on a large image? I think it will be very hard for enough high quality, stable, trustworthy plugins to be available. I'm sure compression, encryption, and a few other basics will be great. But will they do the same as for Photoshop? I doubt it. No one wants to take a risk of widespread data corruption or data loss.

  29. Choose the Filesystem that fits you by El+Prebso · · Score: 2

    I think alot of people are to focused on XFS, Ext3 and ReiserFS competing with each other. Why can't Linux have three filesystems???

    I like ReiserFS and I found that it's completly stable, it has never crashed. Others like XFS and that is fine by me, just don't tell me that my choise is wrong, I'll decide that for myself.

    The great thing about Linux is that it let us choose what we want and don't give us what some dude i Redmond thinks we want. Let us have have 3,4 or 8 filesystems, then the user can choose what filesystem he or she want to use.

    --
    I didn't say it was your fault. I said I was going to blame it on you.
  30. Get ready for the RDF? by lowe0 · · Score: 3

    Quote: "we hope that plugins will do for filesystems what they did for Photoshop."

    What, make them run 55% faster on a Mac than on an equivalent PIII?

  31. Re:First things first... by Lozzer · · Score: 2

    From the interview

    So, ReiserFS finally did make it to the 2.4 series. Now what? You mentioned on the list that current development work is now focused on version 4. Would you provide a general overview of what can we expect from this version?

    We are now all focused on jumping on every bug report that comes in, determining if it is not a hardware bug, and if it is a real bug fixing it immediately. We will stay that way for several more weeks until it is very clear to the community that the experimental label should come off (this is hard when new VFS/MM layer bugs keep showing up), and then v4 will start.

    Not every day a big name in software grants your wishes...

    --
    Special Relativity: The person in the other queue thinks yours is moving faster.
  32. Has the world gone totally mad? by peccary · · Score: 4

    For almost ten years I worked on networked filesystems, and the US government prevented us from adding any kind of "hooks" on the basis that they might be used by furriners to add prohibited crypto.

    Now the US Defense Department is paying a bunch of Russians (oh, the irony, the irony) to do exactly this!

    And the Bush administrations is paying Osama bin Laden 40 mil for his valiant efforts on behalf of the War on (some) Drugs?

    What's next? An invitation for Fidel Castro to spend the night at the White House and drop E with President Junior? Saturday Night Live quits doing White House satires because "we just can't keep up"?

  33. You got the url wrong by iplayfast · · Score: 4

    It's www.reiserfs.com

  34. Re:great news, xfs by InsaneGeek · · Score: 5

    They way I see it is that Reiser is looking to make a mark with having the latest & greatest feature list, XFS is looking to have the the most stable & reliable filesystem, and ext3 is a way to have people keep their existing ext2 data and add journaling support.

    Reiser is planning on selling their modules in the future, make a new feature to be sold and change the previously sold module to be free. Their entire business model depends on them having newer and newer features, which is great for people who are wanting/needing feature over stability.

    XFS is leaning more towards the datacenter type of situation, it may not have the latest and greatest, but it will work reliably, constantly, and with great performance. XFS is looking towards Linux as their OS platform, they have to give the same quality of filesystem they had on Irix to their customers who demand that quality. (when buying a multi-million dollar 512proc numa system they tend to require lots of stability).

    On the competeing filesystems, Steve Lord from the XFS mailing list said it probably best:

    "...I have never regarded the different filesystem on Linux as being in direct competition with each other, there will always be benefits to using each different filesystem for their strong points. Plus having several filesystems under active development means that there will be a tendency for the developers to make theirs the best, the implementations improve, and everyone wins."

    Reiser will be used for the things it's good at (squid, mail spool, new features) and XFS will be used for the things it's good at (larger files, NFS server, stability). They compete only that they are filesystems, but what they are designed to be good at are two different things.

  35. NFS plugin? by oingoboingo · · Score: 3
    Hopefully Hans will also provide an NFS plugin too...relatively recent versions of ReiserFS cause large-scale crapping out of your NFS server when you try and export ReiserFS volumes.

    I won't be rushing again to stick ReiserFS on an NFS system any time soon....

  36. RTWP by Modular · · Score: 3

    Actually he feels that it's relational databases that are crippling. In his whitepaper advocating a unified namespace, he proposes a hierarchical model that fits to data rather than fitting the data to the model.

  37. Photoshop plugins? by egjertse · · Score: 5
    Looking forward to these filesystem plugins:
    • "Random noise" - randomly copy from /dev/urandom instead of writing the actual file
    • "Motion blur" - bit rot on very fast disks
    • "JPEG compression" - lossy compression for your data!
    • "Mosaic" - increase fragmentation
    • "Colorize" - rot13 all .so files
    • "Watermark" - digitally sign all files (also system files)
    How about just making a toolkit for porting Gimp plugins?
    --
    ^]:wq!^M
    1. Re:Photoshop plugins? by Hater's+Leaving,+The · · Score: 3

      Hot-diggetty man, I need mod points _now_!

      You forgot
      * Invert - learn to read documents backwards...
      * Fade - You didn't need _all_ of the data did you?
      * Rotate - Put data on the next sector to the one the FS headers say it's on.
      * Merge - Great if you're short of space.

      THL.
      --

      --
      Keeping /. cynic density high since the fscking Kwhores/trolls arrived.
  38. Fame by 3G · · Score: 4
    Reiser also touches on issues of international software development and how programmers can achieve fame.

    That should be pretty easy - create a kick-ass piece of software that everybody uses & name it after yourself (like he did :).

    --
    Blue skies... Barthie burgers... girls.
  39. encrypted, compressed, journaling.... by Arethan · · Score: 2

    okay....
    And you expect to boot off of your encrypted/compressed drive how again?

    Forgive me if I'm wrong, but you need to read the module files off the hard drive in order to load them and use them, but you need the modules loaded to read the drive... Kind of a chicken before the egg problem?

    Lol. (Yea, I know. Boot partition is a standard FS the kernel and bootstrap prog can read and keep your FS module files on a non encrypted/compressed drive. But still, it's funny. I'm sure that more than a few newbies are going to forget about this little problem, move their module files to the encrypted drive, and then when they next reboot it won't work. *grin*)

  40. I agree by ishrat · · Score: 2
    I am all for this viewpoint that developers should at least get fame if not money, which in any case they may not be too interested in.

    "I now tell people that I firmly advocate making the names of the programmers as prominent on the code as possible, especially when it is free software, and the sponsors should also be prominent on the code. People who do something should get either fame or money as their reward for it, and for free software to succeed we have to maximize the amount of fame that goes around. I think it is a complete rip-off that Stallman's name is not on every Linux distro (or at least the name GNU). It hurts his ability to command attention from people outside the industry who don't know much about us, and it is simply unfair. Failure to cite properly is considered an offense in academia, and it should be considered an offense in the free software community."

    --

    There's always sufficient, but not always at the right place nor for the right folks.

  41. stability?? by codefreez · · Score: 2

    How stable can a FS with plugins be? Some third party's bad code can make your files go bye-bye. I'm sure the security implications would be heavy too. Viruses planted in plug-ins would be too easy to implement and distribute.

    1. Re:stability?? by Hater's+Leaving,+The · · Score: 3

      Given that it's only as stable as the weaker of
      - ReiserFS itself
      - The provider of the plug-in.
      and that ReiserFS itself is stable, you do have to be careful with your choice of plug-in.

      If you care about your files be as careful about your plug-ins as you are about the manufacturer of your brake-disks, or your gas oven, say.

      No-one will _force_ you to use any particular plug-in, you simply have to look for advocacy stories, and make sure you're not on the bleeding edge.

      THL.
      --

      --
      Keeping /. cynic density high since the fscking Kwhores/trolls arrived.
  42. First things first... by Matthias+Saou · · Score: 3

    Before going into implementing new features, I'd prefer if they made ReiserFS rock solid first.

    At the moment, and after hearing recent scary stories about problems with ReiserFS (but I personnally haven't ever had any big trouble), I switched to XFS and enjoy it just as much.

    I also find SGI much more quick at getting things stable and finished, which is fairly important IMHO.

    Matthias

    --
    -- Life wasn't meant to be easy...
  43. Re:Like Frank Xia ... by Pogue+Mahone · · Score: 2

    ... or James V.Fat, author of the VFAT file system. Or Sid Mips, who has a whole architecture
    port named after him. Or Georg Keyboard, Enzo Tpqic02, ... the list is endless.

    --
    Every bloody emperor has his hand up history's skirt [Peter Hammill/VdGG]
  44. Bzzz wrong. compress-y jounaling-y crypto-no by glrotate · · Score: 2

    Encryption debuted in Win2k

  45. Attitude of ReiserFS's developers/backing company by MwtrV · · Score: 2

    RE: ReiserFS, revolutionary...

    From what I have read thus far on ReiserFS and how they are planning on charging for plugins in the future along with ports, XFS seems like a slightly better choice for those concerned with the aesthetics of a project. I don't mean to be a "FREE!" bigot, but I wouldn't want to run something on my system next to the very core of Linux that didn't match the philosophy of it's neighboring code. I hope XFS finds a place in the kernel -- it deserves it a lot more -- and politics casts ReiserFS out. I know the argument: "People have to eat!" Well, that's fine and dandy, Certainly ReiserFS should be available. I just don't think XFS should be left out of the tree if it is embracing more platforms and has no commercial "options" (thus, making it more free.)

    From the ReiserFS FAQ: "15.Can I use ReiserFS on other architectures than i386? Yes, on DEC Alpha. You may be able to easily bribe us to do the port though...."

    From the XFS FAQ: "Q: Does it run on platforms other than i386? The current XFS tree seems to work just fine on ppc now (aside from some trivial compile fixes). It also runs well and is getting sporadically tested on the alpha, sparc64 and ia64. But on all of those platforms it is
    not as well tested as on i386, but so far there are no major problems on those platforms known. All in all it looks like XFS will be running across a lot of platforms fine soon (with all the platforms above we have 32/64bit and little/big-endian architectures supported. If you run it on a platform not mentioned here please
    let me know so that i can add it. Also an important note is that XFS is inherently platform independent in the on disk layout - so it should be possible to move a XFS disk from one linux platform to another out of the box."

    --
    mwtr / THIS SIG HAS BEEN PRAYED OVER AND MAY BE USED AS A POINT OF CONTACT (ACTS 19:12)
  46. Why in kernel space? by janpod66 · · Score: 2
    I think putting ReiserFS into may not be a good engineering tradeoff. What are the tradeoffs? We gain the following:
    • ReiserFS allows very fine-grained access control, on a "per field" (per file) basis. But is that really needed for the kinds of databases it is intended for? The main applications listed for it, databases, file servers, and desktop applications, either have a front-end application that performs its own security checks, or they run on behalf of a single user. Furthermore, even if fine-grained access control is needed, the set of user ids known to the kernel often does not correspond anymore to the set of users authorized to access the data.
    • Being in the kernel, all applications use it automatically. But if we put a database into libc and hooked it into the file system calls, we'd get almost the same benefits.

    What are the disadvantages of putting it into kernel space?

    • Performance. Currently, it takes several system calls to access a data item in ReiserFS. That's a lot of overhead.
    • Slow evolution. ReiserFS could benefit greatly from additional API calls, but adding those is a big hassle because they need to become ioctls or new system calls.

    Maybe ReiserFS is the best we are going to get and the only way in which people are going to migrate to something less impoverished than the current UNIX file system data model. But I still think it's not a good engineering tradeoff overall.

  47. They actually make money.... by the_radix · · Score: 2
    We are one of the very few companies making it on selling purely software, all the others sell CDs or hardware or something. This means the open source business model is a very bad one at the moment.

    She has a darn good point on this. If all that Linsux companies can do is produce pieces of plastic to buy, then I am definitely going to take my money elsewhere. The reason I buy software that is not open source is because I can't get the sources.

    Is open source bad? No, just the business model. It's a decent community, it just doesn't work in the corporate world. I know very few people who, faced with a free choice and a paying choice, both of which are perfectly legal, will take the payment route.

    --
    This .sig is either false or a paradox.