Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Data Storage

Interview With Reiser4 Author Hans Reiser 382

Posted by CmdrTaco from the protect-your-bits dept.
An anonymous reader writes "KernelTrap has an interesting interview with Hans Reiser, the author of two revolutionary Linux filesystems, Reiser3 and Reiser4. Reiser3 was the first journaling Linux filesystem. Reiser4 is a complete rewrite that is claimed to offer amazing performance and a new plugin architecture offering semantic enhancements to rival Microsoft's WinFS and Apple's Spotlight. Comparing Reiser4 to WinFS, Reiser says in the interview, "Reiser4 is a much more mature design, representing a 10 year effort"."
This discussion has been archived. No new comments can be posted.

Interview With Reiser4 Author Hans Reiser More

Interview With Reiser4 Author Hans Reiser

Comments Filter:

  • Homework (Score:3, Funny)

    by mysqlrocks ( 783488 ) on Tuesday September 13, 2005 @10:59AM (#13547941) Homepage Journal

    Berkeley was a lot better than junior high school, but it still involved homework, which deep down in my heart I could never believe in.

    I hear you. I always avoided homework as much as possible too.

    • "Berkeley was a lot better than junior high school, but it still involved homework, which deep down in my heart I could never believe in."

      I hear you. I always avoided homework as much as possible too.

      Your comment might be funny, but remember that according to Penn State researchers, too much homerwork can be counterproductive [slashdot.org]... Reiser might have a point after all.
  • I was wondering over the weekend, on a whim, whether it would make sense to create a cross-platform library that abstracts meta-data/search functionality. Like, it would provide one uniform set of utility functions, and this would turn into calls to WinFS on windows, calls to Spotlight on OS X, and calls to ReiserFS on Linux.

    But I don't know enough about WinFS OR Spotlight Or ReiserFS to know if this would be even remotely useful or is just nonsense ;)
    • patent first, ask feasibility second.

    • Re:I was actually just wondering (Score:4, Insightful)

      by RAMMS+EIN ( 578166 ) on Tuesday September 13, 2005 @12:07PM (#13548574) Homepage Journal
      It would be difficult to design. If you look at what APIs exist for this sort of functionality, pretty much the only one that has a significant amount of traction is SQL. And SQL isn't exactly the nicest language to work with. It's implemented with various degrees of compliance and non-standard extensions by various databases. Outside of SQL, the landscape is even more scattered.

      SQL language itself is somewhere in between being a very restrictive domain specific language and a full programming language. The way it is used in practice is by calling it from a real programming language, usually through an interface that leaves the door wide open for injection vulnerabilities.

      I believe the problem is that it's difficult to figure out what functionality goes where.

      If you want to get a list of all files that have been modified since monday and whose name does not start in a period, how do you proceed? Do you get a list of all files, then throw away all but the ones modified since monday, then discard all the ones whose names start in periods?

      Do you get a list of all files whose names do not start in periods, then discard all files that have been modified since monday? That requires your search interface and implementation to somehow support intelligent matching of the names (more difficult than getting all files whose names start in periods).

      Or do you directly query the system for what you want? In that scenario, your interface and implementation have to support complex queries, with subqueries, unequality operators, etc. Are you going to implement all this functionality, just because someone might need it? Is anyone going to be able to understand or implement your interface?

      I would love it if a good and cross-platform interface were available, but I don't think it's ever going to happen. If not for the technical difficulties, than because Microsoft won't want to adhere to the standard.

  • WinFS? (Score:2, Funny)

    by Anonymous Coward
    Does that actually exist?

    I thought It was dead...

    Let's try to keep our comparisons to real entities...

  • Hans and Franz (Score:4, Funny)

    by Anonymous Coward on Tuesday September 13, 2005 @11:01AM (#13547960)
    I am Hans, and this is Franz, and we want to [clap] journal your filesystem.
    Ya. Ya. All you little girly men with your FAT and NTFS!
    Really, Ya. Makes me sad to see such pathetic file systems!
  • How does the performance of Reiser4 compare to that of Reiser3, XFS, JFS, EXT2/3, UFS, UFS2, etc., in quantitative terms, for various applications?

    • Re:What exactly is "amazing" performance? (Score:5, Informative)

      by varmittang ( 849469 ) on Tuesday September 13, 2005 @11:12AM (#13548058)
      This one is pretty old review [netnation.com] back when Reiser4 was still Experimental. More recent one would be here [linuxgazette.net], but it too is over a year old.
      • Yeah, I had found those links as well. But I was hoping that somebody had done a more recent (ie. within the last month, if not sooner) evaluation of the performance of various filesystems. A lot of developments take place within the course of a year, so I would be hesitant to take such results as worthwhile in this day and age.

    • Re:What exactly is "amazing" performance? (Score:5, Informative)

      by otisg ( 92803 ) on Tuesday September 13, 2005 @12:09PM (#13548597) Homepage Journal
      This is a type of question that, unfortunately, cannot be answered correctly. Well, it can: it depends. But that's not what you are after. As Hans himself pointed out, there are some fsync performance problems with ReiserFS. If you look at PostgreSQL config files, you'll notice a "fsync" setting, and if you look at pgsql-performance mailing list, you'll see frequent mentions of fsync. Obviously, fsync affects DBs (not just PostgreSQL), and ReiserFS may not currently be so great for DBs. However, it is apparently good for large directories (1 directory, lots of files in it). So, it depends how you use your FS.
      Describe how you use your FS, and maybe somebody can provide good feedback.
  • Journalled filesystems are so 90s. Everyone is raving about how the new whizbang filesystems of the 21st century are going let you do metadata searches, and harken back to the beloved (?) BeOS. Well, what I want to know is: How do I get to this metadata? Some extra tool? Some right-click option that I have to select every time I create a file? Will all File dialog boxes have to be rewritten, and will I have to manually input all this info?
    I'm happier with Google desktop, which can, effectively, search
    • OS/2 actually had file meta deta way back in the days of OS/2 2.0. They called them "Extended Attributes". Unfortunately HPFS was not journaled or transacted, so in the event of system failures, your meta data would get screwed up and you would have to run some goofy utility to fix things.
    • Somehow I think they will be useful. The file/directory concept was born (IIRC) at Multics, and that was because people was starting to have too many files (until then there was no directories, just "files")

      The file/directory idea got spread by unix (except for CP/M, who invented the "unit" bastardization which was inherited by DOS and NT) and it has been nice for 30 years

      But now we have the same problem: We have too many files. The "file/diretory" thing was enought in the 70's because people didn'

    • RTFA (Score:2)

      by uhoreg ( 583723 )
      Eventually, Reiser4 will allow storing metadata in plain old files, so that no special tools will have to be used. It will also allow queries done straight through the filesystem. In the interview, Hans says that that functionality is about 3-5 years away when fully implemented, but it will be implemented gradually, so some functionality will be available earlier.

    • Re:Interface to metadata? (Score:5, Interesting)

      by Bogtha ( 906264 ) on Tuesday September 13, 2005 @11:58AM (#13548495)

      Well, what I want to know is: How do I get to this metadata? Some extra tool?

      One of the driving concepts behind ReiserFS is that metadata is nothing special, and it should be presented in the same namespace as the files themselves. If you read the article, it talks about using 'cat' and other simple tools to manipulate the metadata. Think something like 'cat /home/foo/music/some.mp3/artist' to display the person who performed a song.

      Some right-click option that I have to select every time I create a file?

      It depends on the metadata. Think about file permissions. That's metadata. All the files you create are given defaults based on your umask, and you can go in and change them at any time.

      In order to expose some of this metadata to the end-user in a GUI, yes, there will probably need to be some new UI work done. It doesn't all just magically work, it has to be presented to the end-user in some way that will make sense to them. So what I would expect is that the filesystem and plugins will be finished and done, and able to be manipulated by programs and shell scripts, and then it will take further work to integrate this metadata support into GUIs and file managers in a way that's useful to non-power-users.

      • Re:Interface to metadata? (Score:5, Interesting)

        by ArsonSmith ( 13997 ) on Tuesday September 13, 2005 @12:55PM (#13549080) Journal
        Another thing I thought sounded cool was the ability to cat /home/foo/music/some.mp3/raw > /dev/dsp and the mp3 would just play by using a plugin that ran it through an mp3 library. This would allow application developers to just access file/raw rather than worrying about file types and conversions.

        If I'm writing an image viewing program I no longer have to worry about hooks to libjpg, libungif, libpng, libevery image file type available. Let the OS care about file types and let applications deal with raw data and focus on interface rather than file types.
        • This would allow application developers to just access file/raw rather than worrying about file types and conversions.

          Is that raw data big-endian or little-endian? How many bits per sample? What's the sample rate? How many channels? Interleaved or no?

          Will that pseudo-file support seeking? What sort of units will you seek in -- bytes, samples, frames, or seconds?

          What if I try to read 3 bytes, but the frame size is 4 bytes? My 3-byte read will never return any data, even though there's data left in the

          • Is that raw data big-endian or little-endian? How many bits per sample? What's the sample rate? How many channels? Interleaved or no?

            Well, noone stops you from opening and reading 'file/raw/bps', 'file/raw/endianness' etc. As long as we can agree on the common namespace for all audio files, I don't see why it won't work.

            Will that pseudo-file support seeking?

            Yes, if the plugin supports it.

            What sort of units will you seek in -- bytes, samples, frames, or seconds?

            Since file (even a pseudo one)

            • Well, noone stops you from opening and reading 'file/raw/bps', 'file/raw/endianness' etc. As long as we can agree on the common namespace for all audio files, I don't see why it won't work.

              OK, but that won't work for the "cat file.mp3/raw > /dev/dsp" case.

              The point of my criticism is that raw audio data isn't self-describing, so unlike text, you can't pipe it around without supplying some metadata. IMO a better solution than what you propose is to support an interface like file.mp3/wav, which is raw dat
    • ``Well, what I want to know is: How do I get to this metadata? Some extra tool? Some right-click option that I have to select every time I create a file? Will all File dialog boxes have to be rewritten, and will I have to manually input all this info?''

      How does metadata get into the ID3 tags of MP3s and the comments in Ogg Vorbis files? Wouldn't it be nice if that info were available through a standard interface? Wouldn't it be nice if the same interface provided access to metadata about movies? Webpages? I

    • Re:Interface to metadata? (Score:5, Insightful)

      by sasami ( 158671 ) on Tuesday September 13, 2005 @12:26PM (#13548797)
      Well, what I want to know is: How do I get to this metadata? Some extra tool? Some right-click option that I have to select every time I create a file?

      Anytime you save a file today, you're already manually specifying several pieces of metadata: the filename and the location.

      Anytime you access a file today, you're already manually specifying that metadata also.

      Consider how many clicks it takes to (graphically) navigate to a file from the root directory. That is exactly the number of metadata labels that you yourself supplied for that unique file's creation.

      So, the obvious generalization of this is to get rid of the hierarchy concept entirely. Then, as an earlier poster described, I can naturally tag my music by artist and by genre, instead of using symlinks to cut across trees.

      More practically, it would allow applications to install themselves using a unique tag, so that uninstalling (or moving, or archiving) the application requires just one query on just one tag, and is guaranteed to turn up any associated file regardless of its "location."

      --
      Dum de dum.

    • Re:Interface to metadata? (Score:4, Informative)

      by 99BottlesOfBeerInMyF ( 813746 ) on Tuesday September 13, 2005 @12:34PM (#13548897)

      Well, what I want to know is: How do I get to this metadata? ...Once there's an application which can find all pictures of my dog, or songs with piano in them, and store THAT in the metadata, which I can search somehow, call me.

      I take it you have not actually tried to use any of these new filesystems and their metadata. Metadata comes from lots of places. It comes from an internet database of music CD and movie DVDs. It comes from the OS intelligently reading the text contained within various file types (like text, rtf, .doc, PDF, PS, etc. etc.) and extendable by a plug-in type architecture. It comes from applications who assign it based upon given criteria, or from applications that create files which are now starting to assign more and more metadata to those files. It comes from hardware, like when your digital camera or PVR assigns dates to files it creates. It comes from users inputing it by hand, like when they go through their vacation photos and add a description for each picture.

      I use this metadata and perform searches on it every day. Why shouldn't I be able to do an easy search on my computer for every document, application, library, etc. that has the string "vpn" in it? Shouldn't I be able to find all references to MPLS in my files, whether or not they are in in text, .doc, .pdf, or some other file format? Shouldn't applications on my system be able to find and edit this data as well? Well, now I can (and they can) and I really, really like it.

      For some reason you are looking at the current limitations of metadata, i.e. optical recognition can't reliably identify my dog, instead of the advantages, which is all the information that can be reliably searched. Maybe right now I can't search for all my mp3's with a piano in them, but I can automatically tag all the audio coming in over the mic I have attached to the piano with metadata that says it is piano. Now fast forward 10 years and suddenly all of your files have a wealth of automatically generated data associated with them. In 10 years I will be able to search for all the mp3's that have piano in them, because my audio mixing program labels all the files with input from the piano mic with the proper metadata and why not. For a few seconds work up front I, and everyone using my files, gets additional functionality. Now apply that to all files from all sources and suddenly metadata has greatly improved the computing experience.

      Get with the times, metadata in the filesystem is here and it is very useful and it is becoming more and more useful every day.

  • Non-wide page link (Score:5, Informative)

    by Alan ( 347 ) <arcterexNO@SPAMufies.org> on Tuesday September 13, 2005 @11:11AM (#13548053) Homepage
    Here's a link [kerneltrap.org] to the page that hides the asshats making the pages super-wide with lame comments.

  • When will it be "safe" to use? (Score:3, Interesting)

    by bad_outlook ( 868902 ) on Tuesday September 13, 2005 @11:19AM (#13548126) Homepage
    I've been waiting until it's deemed "safe" to use, but it seems it's going on 2 years now or "not ready yet". I know it's ready when it's ready, but is there a timetable for it? I don't have a fast enough spare box to test it out, and I want to dig the faster FS perf on an SATA harddrive. Keep going Hans!
    • Many people (including myself) have been using Reiser4 for quite a while now without any problems. The developers have stopped being able to find bugs, as far as I've heard, although the occasional bug does pop up on the mailing list (and is fixed rather promptly by the developers). When Reiser4 gets included into the mainline kernel and the number of users increases by an order of magnitude, it will be likely that some new bugs will be found. I might not trust million-dollar, mission-critical data on it

    • Re:When will it be "safe" to use? (Score:3, Interesting)

      by Anonymous Coward
      It is very stable already - I use it as the root filesystem on my laptops (mostly because laoptop disks are sooo slow and reiser4 mitigates this considerably).

      I have not suffered any problems whatsoever in more than a year. I have had power-cuts, battery problems, and even a few kernel panics and so forth due to ACPI bugs, and reiser4 hasn't lost a single file or even needed a fsck.

      Not to mention that its fast as hell.

      I still do make weekly backups though, since I don't trust the disk to survive very long -

  • For desktop use: UFS2 versus ReiserFS3. (Score:3, Interesting)

    by CyricZ ( 887944 ) on Tuesday September 13, 2005 @11:26AM (#13548191)
    I recently switched a laptop from Linux with ReiserFS3 filesystems to FreeBSD 5.4 using UFS2 filesystems. The size of the filesystems were the same, and the usage pattern (program development, web browsing, etc.) the same.

    The UFS2 filesystems had the feel of being quicker than the ReiserFS3 filesystems. That said, I do not have any numerical data to back this up. However, untarring a large tarball consisting of many smallish files under FreeBSD felt quicker than doing the same under Linux.

    Would this difference be caused by the filesystems themselves, or would it most likely be a difference between the Linux and FreeBSD IO subsystems? Would ReiserFS4 be more comparable, if not better than, FreeBSD's UFS2 for workstation-style workloads?

    • There could be a lot of reasons. Because of soft updates, FreeBSD is much more aggressive about metadata caching, which might explain why you're noticing the improvements for creating large number of smallish files (most of the I/O there is metadata updates). There is also just one filesystem for FreeBSD, making optimizations much easier. On Linux, optimizing for e[23]fs may really hurt the performance of XFS and vice versa, for example. Also, journalling filesystems are always slightly slower on writes

  • Huh ? (Score:4, Interesting)

    by drsmithy ( 35869 ) <drsmithy@gm[ ].com ['ail' in gap]> on Tuesday September 13, 2005 @11:30AM (#13548225)
    Comparing Reiser4 to WinFS, Reiser says in the interview, "Reiser4 is a much more mature design, representing a 10 year effort"."

    Comparing ReiserFS and WinFS is a bit like comparing Qt and Explorer - nonsensical. They're different things, operating at different levels, to serve different purposes.

    Come on, how are the parties involved supposed to carry any credibility when making such a *basic* and *fundamental* misunderstanding - /WinFS is not a filesystem/. They also seem to misunderstand what Spotlight is - again comparing it as a filesystem, when it isn't.

    • On top of that, I remember reading about the nifty stuff that was going to be in WinFS way back when Windows NT 4.0 came out -- in 1996!

      WinFS has also been a long time coming. Though I suppose 9 years isn't as exciting as 10.

    • Re:Huh ? (Score:5, Informative)

      by quasi_steller ( 539538 ) <Benjamin,Cutler&gmail,com> on Tuesday September 13, 2005 @12:17PM (#13548681)

      Comparing ReiserFS and WinFS is a bit like comparing Qt and Explorer - nonsensical.

      Are you sure you understand what ReiserFS is suppose to do? What about WinFS? I don't think compairing WinFS to ReisierFS is quite like compairing Qt to Explorer. The functionality of WinFS is (as I understand things) a proper subset of the functionality of ReiserFS.

      They're different things, operating at different levels, to serve different purposes.

      Again, there purposes are not really different. Sure, ReiserFS is a full blown filesystem, and WinFS is not a filesystem, however the functionality of WinFS is included in ReiserFS. The fact that they operate at different levels is the reason for Reiser's remarks concerning ReiserFS and WinFS. That's his point. WinFS works on a user level to provide functionality that ReiserFS provides at the filesystem level, and Reiser feels that this is a more mature design.

      • Re:Huh ? (Score:5, Informative)

        by jiushao ( 898575 ) on Tuesday September 13, 2005 @04:01PM (#13550871)
        Are you sure you understand what ReiserFS is suppose to do? What about WinFS? I don't think compairing WinFS to ReisierFS is quite like compairing Qt to Explorer. The functionality of WinFS is (as I understand things) a proper subset of the functionality of ReiserFS.

        Sorry, but ReiserFS v4 is a tiny subset of WinFS. I would say that the grandparents analogy is apt.

        To clarify: ReiserFS adopts database concepts in two ways. It uses a B-tree variation to allow efficient hierarchical storage layout and it uses it to allow single-process atomicity. That is all.

        WinFS on the other hand is an actual factual relational database (actually parts of MS SQL-Server) built on top of NTFS; a NTFS file is a special datatype among many others. One can specify relations and constraints as one would in a relational database. It has full atomicity (ACID), whereas ReiserFS's atomicity just gives a rollback local to a process. That is, any read or write may be transactionally inconsistent if there is more than one process dealing with the data whereas in WinFS one gets full support for transactions.

        In addition to the above WinFS of course provides the obvious big end-user features; Fast queries over all the data in a relational way, and triggers that allow actions performed when data is changed or queried (both of which OSX provides in a slightly more ad-hoc way on the side).

        So where does ReiserFS fit in? Well, the complaint that Hans Reiser has against WinFS is that not everything is a file, rather files is a special case mapping down to NTFS streams. Small auxilliary data is handled by other data-types in an SQL-like manner in WinFS, which to me at least seems like a quite sane approach. ReiserFS instead just optimizes the heck out of small files, planning to just take the UNIX principle to the limit, everything is a file, even if you just want to store a small integer. This makes everything fit into the classic filesystem namespace in a good way, but it is really less structured than the WinFS approach. WinFS relates whereas ReiserFS just provides really fast unstructured primitives.

        Overall I don't expect ReiserFS to be overly relevant to the OSS answer to WinFS, mostly because I don't really expect a OSS answer to WinFS on that level. While Microsofts approach is a great piece of engineering is is also a huge amount of work. More likely is that the Apple approach will continue to be the important one; Just add the stuff needed to get the actually important end-user features today, work on the low-level programmer features later.

        On the other hand ReiserFS v4 really appears to be very very fast. No doubt great features can be built on top of it, but on the other hand the classic VFS abstraction is a good thing. Swapping filesystems without impacting the userland is a feature that is really useful, so it seems fairly likely that the simpler approaches like Beagle will get to add the basic end-user features instead of fattening up the file systems (I highly disagree with Reiser that it is on the actual FS-level things should happen in the future). People who need databases can, *gasp*, use a database instead.

        In fact, I am suprised to not yet have seen systems like Gnome and KDE fire up a stripped down PostgreSQL process or something similar to provide applications with an excellent database for whatever their needs might be. For Microsoft doing a thing like that hurts the bottom line (they do charge a fair bit of money for SQL-Server after all), but there is no reason why an OSS platform should not utilize the best technology it has available at every turn.

        Oh well, getting off track. Summary: ReiserFS v4 is a tiny subset of WinFS feature-wise, it just does it very very fast.

    • Re:Huh ? (Score:4, Funny)

      by manyoso ( 260664 ) on Tuesday September 13, 2005 @12:19PM (#13548713) Homepage
      "/WinFS is not a filesystem/"

      Then what does the FS stand for in the name? "Full 'o Shit"?

      And on the other side, I think I'm going to trust that Hans fucking Reiser knows what a filesystem is. Idiot.

  • Did they ever fix the performance issue? (Score:3, Interesting)

    by james_shoemaker ( 12459 ) on Tuesday September 13, 2005 @11:33AM (#13548261)
    Last time I used Reiser I had to reformat back to ext. The starving problem basically made the kernel freeze when flushing buffers during large streaming writes. Is the Large writes starve reads issue gone yet? When I say large I am referring to streaming 12 gig (hour of DV) in a continuous write.

    James
    • That's somewhat irrelevent, since reiser isn't the filesystem you ideally want to be using for a few really large files. You want XFS for that (or possibly ext3). Reiser's big thing is good journaling, awesome performance and space usage with a bunch of really small files (think maildirs, where each message is a separate file and probably less than a single filesystem block) or "regular" usage. It works with huge files, but that's not really where it shines.

      That said, I have no problems with reads during

      • Re:Did they ever fix the performance issue? (Score:4, Interesting)

        by pe1chl ( 90186 ) on Tuesday September 13, 2005 @12:12PM (#13548627)
        The problem is not really related to large files.
        When you copy a big tree from one disk to another, where the destination is Reiserfs (source may be Reiserfs as well) it is going to be slow.
        There is something in Reiserfs that causes the system to keep too much filedata in memory during writes. At some point it even starts to swapout running programs to make room for buffers for the writing, instead of just writing them to disk and freeing for new operations.
        The result is the "freeze" problem: everything you touch happens to be swapped out and needs to be brought back in, and all system RAM is used for useless buffers.

        Try copying something like 20-30GB on a system with 1GB or less of RAM, that should show the problem.
  • reiser1 and reiser2

    did they exist? if so what were they like?

  • bring on the meta data (Score:2, Interesting)

    by cerelib ( 903469 )
    I really would like a metadata driven system. Instead of the traditional file dialog for saving or opening files it would be cool to just specify some metadata and have it thrown on a heap of files. I think this is kind of what winFS is trying to accomplish, but above the filesystem level. Hopefully that is in the future of every OS. And if not, or is some better idea comes along, then I guess some time in the future I will pick up a database implementation book and a file systems book, study up and wor

  • 10 years? (Score:2, Funny)

    by jshaped ( 899227 )
    "Reiser4 ... representing a 10 year effort"

    obligatory comment:

    by the time longhorn (vista?) is released, it too will be a 10+ year effort.

  • 10 year maturity (Score:4, Interesting)

    by LordMyren ( 15499 ) on Tuesday September 13, 2005 @11:52AM (#13548438) Homepage
    Normally you have to release something before it can mature. OTherwise its called development...

    Still waiting on that plugin system, thanks. Should be good though. No hurry, but if you could even begin to release some info on /how/ its structured, how devels will be able to use it, how we'll be architecting solutions with Reiser4 plugins, it'd be much appreciated.

    -Lord "I hope I havent missed anything in all these years waiting" Myren

  • Required reading (Score:3, Informative)

    by grahamlee ( 522375 ) <graham.iamleeg@com> on Tuesday September 13, 2005 @11:58AM (#13548485) Homepage Journal
    People who think they need to implement spotlight, HFS+ xattrs or Reiser should read Practical FileSystem Design (pdf) [nobius.org] then just go away and use BeFS instead.
    [Actually, the person who implemented HFS+ xattrs and worked in the Spotlight team was the guy who wrote Practical FileSystem Design, so I think that counts :-)]
  • run Linux... oops, I mean, will 2.6.14 ship with it?

  • Other filesystems: XFS (SGI) and GPFS (IBM) (Score:3, Informative)

    by otisg ( 92803 ) on Tuesday September 13, 2005 @12:01PM (#13548513) Homepage Journal
    There are 2 other significant players in the FS field that Hans doesn't mention:
    XFS [sgi.com] (from SGI) and GPFS [ibm.com] from IBM.

    GPFS has a different focus, but XFS seems to be aimed at solving similar problems as ReiserFS (scalability, high performance, journaling).

    • IBM's JFS (Score:3, Interesting)

      by jd ( 1658 )
      I believe IBM's JFS (which, as its name implies, is a journalling filesystem!) was one of the first journalling filesystems for Linux - it beat SGI's XFS on being first out the door, although IBM took longer to get it stable. SGI were really quick to move from a mere code dump to a usable filesystem.

      Not really looked at GPFS, but if IBM's history is anything to go by (JFS, M:N threading, the DAISY code translator, etc) it'll be revolutionary, be an inspiration to a thousand projects, and get forgotten as it

  • general FS question (Score:3, Interesting)

    by nickos ( 91443 ) on Tuesday September 13, 2005 @12:27PM (#13548818)
    I've been thinking about starting up a file system project (as you do), and was wondering if anyone has thought of using something like the FUSE [sourceforge.net] kernel module with a database (say MySQL or Berkeley DB) to create an easily indexible file system. The idea is to create a basic proof of concept using FUSE and if it gets any interest turn it into a proper (kernelspace) FS.

    What sort of problems can I expect to face?

  • Does Reiser4 work in a 64bit environment on AMD64? (Score:3, Interesting)

    by t35t0r ( 751958 ) on Tuesday September 13, 2005 @12:33PM (#13548888)
    The topic in channel #gentoo-amd64 on irc.freenode.net has said "Reiser4 is evil" for more than a year. Does anyone know if Reiser4 actually works in a x86_64 environment?

Slashdot Top Deals

Whoever dies with the most toys wins.

Close