Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
OS X Operating Systems Data Storage

Plethora of New User Space Filesystems For Mac OS X 225

DaringDan writes "As part of the recent MacFUSE 2.0 release Amit Singh has added support for an insane number of filesystems on the Mac. This video from Google and this blog post pretty much explain everything in detail but to sum-up Singh has written a new filesystem called AncientFS which lets you mount a ton of UNIX file formats starting from the very first version of UNIX. Even more interesting is that they have also taken Linux kernel implementations of filesystems like ufs, sysv-fs, minix-fs and made them work in user-space on the Mac, which means its now possible to read disks from OSes like FreeBSD, Solaris and NeXT on OS X. ext2/ext3 don't seem to be on the list but apparently the source for everything is provided, so hopefully some enterprising soul can apply the same techniques to ext2. One of their demos even has the old UNIX kernel compiled directly on the Mac through the original PDP C compiler by somehow executing the PDP binaries on OS X!"
This discussion has been archived. No new comments can be posted.

Plethora of New User Space Filesystems For Mac OS X

Comments Filter:
  • by Pope ( 17780 ) on Wednesday December 17, 2008 @11:52AM (#26147099)

    I still have the old Intel Rhapsody DR2 disks lying around, and would love to see if this can read the filesystem. It's kind of fun playing around it what was NeXT with a MacOS interface, and at times I almost would rather have it than what OS X became, if only to eliminate the stupid gimmicks.

    • One man's "stupid gimmicks" is another man's graceful and easy-to-use system.

      I know the above sounds snarky, but I worked on Mac OS Classic for years, and was a linux user at home for years as well. I was *very* put off at first by OS X's eye candy and general fooferah. And then I actually used it ( 8 hours a day at work ), and realized it was fantastic. I ditched my Slackware running thinkpad for a powerbook, and never looked back.

  • Sounds great. (Score:5, Interesting)

    by solios ( 53048 ) on Wednesday December 17, 2008 @11:53AM (#26147115) Homepage

    Especially if I ever need to recover one of my linux box's drives from a Mac.

    But really, all I want for christmas is NTFS write support.

    • Re:Sounds great. (Score:5, Informative)

      by DarthStrydre ( 685032 ) on Wednesday December 17, 2008 @11:57AM (#26147193)

      NTFS-3G which works with MacFUSE has full NTFS write support. It is, however, much slower at reading than the native NTFS read-only driver.

      • Re: (Score:3, Interesting)

        by MMC Monster ( 602931 )

        So why can't you use the native NTFS read-only driver for reads and the NTFS-3G driver for writes?

        • Re:Sounds great. (Score:4, Informative)

          by BrentH ( 1154987 ) on Wednesday December 17, 2008 @02:23PM (#26149461)
          Because he hasnt tried the ublio builds of the nfts-3g plugin: it read and writes with comparable speed to a native filesystems ( I can read/write with 30MB/s on an external USB drive.
          • Yes, but that is unstable. I don't know about you but when I'm making a backup of my media files to my external NTFS drive I would rather have it be slow and stable than risk a corrupt backup.

            You can, however, disable NTFS-3G using the scripts in the TOOLS folder of the DMG and utilize the high speed reading ability until you need read-write. The scripts let you start/stop NTFS-3G.

            By slow, I mean that I get 3MB/s in OSX but if I boot into XP bootcamp I can see ten times that speed.

            • Re: (Score:3, Informative)

              by BrentH ( 1154987 )
              That hasn't been unstable for a long time. Been using it for over a year now on a regular basis, for backups, and I havn't ever had any problems with it. I also havn't actually heard of reports of breakage for over a year, and many reports of succes. It's what Linux ntfs-3g uses too, and the stability/corruption issues just aren't there.

              NTFS-3g is just as stable and performant as a native fs, on both OSX and Linux. Ubuntu even supports it officially with Wubi now.
      • by j-cloth ( 862412 )
        And it has a nasty tendency to corrupt the volume when the power goes out. I haven't had to do so many disk repairs since FAT16.
        • Must be rare (Score:3, Informative)

          Well, for the last year or so, I have been using NTFS-3G every single day of the week, using it to running my virtual machines stored on a USB hard disk (performance is excellent, by the way -- with Linux's tendency to cache the VM images, Windows guest performance is easily better than running natively off a physical partition).

          At my college, and at home, there are computers with faulty USB connectors. A few times a week, when running a VM, my USB cable will wriggle loose, and the hard disk will disconne

    • Re: (Score:2, Funny)

      by Anonymous Coward

      But really, all I want for christmas is NTFS write support.

      Santa Jobs says you've been naughty. COAL filesystem support for you this year!

    • Re: (Score:3, Informative)

      by JonLatane ( 750195 )
      Merry Christmas []. NTFS-3G is more than fast enough to read documents from your Windows partitions. The only time its slower speeds will really be a noticeable problem, in my experience, is if you run OS X applications from your NTFS disk. But why would you keep your OS X applications on an NTFS volume?
      • Or you keep Steam on your windows parition and don't feel like rebooting to get your TF2 fix, so you load it up via crossover. And let me tell you, it is NOT fast enough for that. Load times are considerably longer than in Windows - Garry's Mod is nearly unplayable due to it taking around 30 minutes to load a map.

      • by Artifex ( 18308 )

        Yup. It's been totally fast enough for anything I've used it for, ever since the first MacFUSE came out. Don't forget to get MacFusion, too, if you also want to easily mount sshfs or ftpfs right in Finder. Other than screwed up space free counts (sshfs issue) it's teh sexxy.

  • ext3 (Score:5, Insightful)

    by fracai ( 796392 ) on Wednesday December 17, 2008 @12:04PM (#26147323)

    What is needed is an ext3 implementation. There've been projects to bring ext2/3 to the Mac, but so far they've been incomplete and abandoned.

    I'm actually pretty surprised that this hasn't been properly implemented already.

    • by Hatta ( 162192 )

      Why would you want a FUSE implementation of ext3? Wouldn't it be better to port it to the Darwin kernel and use that on OS X?

    • I personally think it is ridiculous... I have been fiddling with installing osx86 and one large stumbling block is bloody file systems! I thought I had it figured out, where I have large storage partitions partitioned with ext3 so that with extifs (or whatever) I can read and write them from windows and they are all good in Linux.

      Now I install OSX and it turns out apple can't even implement a very popular(presumably well documented) open source file system! Now you tell me they don't even write NTFS!!! Bloo

  • A couple years old, but ext2fsx [] still works.

    • Re:ext2 on Mac (Score:4, Insightful)

      by mrsteveman1 ( 1010381 ) on Wednesday December 17, 2008 @12:25PM (#26147705)

      If by "works" you mean "i have a 10.3 panther PPC machine and need non-journaling access to an ext3 partition", or "i have a tiger/leopard Intel machine and don't care if my machine suddenly panics". Those are the choices at the moment.

      It's curious really, this is a filesystem for which the spec is very well known, implementations are available fully open source, and yet here we are with unmaintained and unstable projects that are alpha quality for both OS X and Windows. The drivers for Windows ext2/3 support cause bluescreens under various conditions, so yea those are alpha too.

      • It kinda works for me on Leopard (PPC Mac), but it refuses to mount read/write ext3 filesystems with the dir_index feature. So, just read-only for me.
  • So it supports and insane number of filesystems just not the two most popular ones?

    Insane's the word...

  • FUSE for Windows (Score:3, Informative)

    by Cyberax ( 705495 ) on Wednesday December 17, 2008 @12:47PM (#26148067)

    Also, it seems to be a good time to plug Dokan and my FUSE4Win project :)

    There's a wonderful project named "Dokan" (, it makes posssible to write user-space filesystem in Windows.

    I've adapted FUSE interface for it, so it's possible to use (almost) unmodified FUSE filesystems in Windows: []

    Currently, SSHFS works fine. NTFS3g also works :)

  • Too bad it for the mac, lets make it work under Ubuntu so it can be useful to those of us who don't want to overpay for our hardware.

  • A Plethora? (Score:5, Funny)

    by Ignatius D'Lusional ( 1010911 ) on Wednesday December 17, 2008 @01:11PM (#26148461)
    Jefe: I have put many beautiful new user space filesystems in the Mac OS X, each of them filled with little suprises.
    El Guapo: Many new user space filesystems?
    Jefe: Oh yes, many!
    El Guapo: Would you say I have a plethora of new user space filesystems?
    Jefe: A what?
    El Guapo: A *plethora*.
    Jefe: Oh yes, you have a plethora.
    El Guapo: Jefe, what is a plethora?
    Jefe: Why, El Guapo?
    El Guapo: Well, you told me I have a plethora. And I just would like to know if you know what a plethora is. I would not like to think that a person would tell someone he has a plethora, and then find out that that person has *no idea* what it means to have a plethora.
    Jefe: Forgive me, El Guapo. I know that I, Jefe, do not have your superior intellect and education. But could it be that once again, you are angry at something else, and are looking to take it out on me?
  • FUSE vs. FST (Score:3, Interesting)

    by HTH NE1 ( 675604 ) on Wednesday December 17, 2008 @01:41PM (#26148877)

    Apple's GS/OS had FSTs (File System Translators) that allowed that operating system to access HFS, ProDOS, DOS 3.3, and FAT volumes. How does FUSE compare in function to GS/OS's FSTs? You know, apart from working with non-obsolete hardware.

    • Re: (Score:3, Informative)

      Apple's GS/OS had FSTs (File System Translators) that allowed that operating system to access HFS, ProDOS, DOS 3.3, and FAT volumes. How does FUSE compare in function to GS/OS's FSTs? You know, apart from working with non-obsolete hardware.

      Fuse is not a file system or even a translation layer per se. It's just a way to let you run a filesystem in userspace, instead of inside the kernel where it would normally reside.

      This is slower, but has many benefits including easy development/debugging, not requiring ac

      • FUSE also has the benefit of already being standard in Linux, so there are plenty of FUSE drivers out there. If FUSE is also available for OS X, and even Win32 (see a few posts above!), it means that you can now write a single cross-platform FS driver.

      • Though as far as I understand, it is more than "just that the OS knew how to read more than one kind of disk". FSTs are plugins, though unfortunately that plugin interface was never documented. In other words, the filesystem access in GS/OS is at least _partially_ abstracted, and the FSTs are what do various things on different filesystems.

        You could also do things like making a remote FTP site appear as a normal file system.

        (That was one of the ideas thought about with the Ethernet card that never came ou

  • As probably the most commonly used filesystem on linux, is ext3 supported by Mac OS X FUSE?

    If not, why not?

    • by Jim Buzbee ( 517 )

      • Latest release:

        ext2fuse v 0.8.1 (June 26, 2008) - Preliminary Mac OS X support, may not work.


        Seriously. Is ext2/3 support that much more difficult than all the other filesystems that fuse supports. It's not as if the filesystem is not well documented. There are probably at least a couple open source implementations of the filesystem as well that they can reference...

    • by Cyberax ( 705495 )

      But why? FreeBSD, Linux and even Windows ( have native ext2/3 drivers which are much faster and feature-complete than FUSE drivers can be. There's just no need for FUSE.

  • FTS:

    ext2/ext3 don't seem to be on the list but apparently the source for everything is provided, so hopefully some enterprising soul can apply the same techniques to ext2

    ext2/ext3 don't seem to be on the list but apparently the source for everything is provided, so the maintainer will be harassed for this feature while the "community" sits idly by.

  • Reiser 4 (Score:3, Interesting)

    by doom ( 14564 ) <> on Wednesday December 17, 2008 @02:55PM (#26149919) Homepage Journal

    Wasn't this sort of thing the idea behind the original "plug-in" mechanism planned for Reiser 4? I remember being intrigued by the idea of writing file-system customizations in perl, and I was looking forward to playing around with it to see what could be done with it.

    Unfortunately, it appears that the kernel devs don't want to hear about any functionality that doesn't fit in the box of their VFS layer.

    • Re:Reiser 4 (Score:4, Informative)

      by SanityInAnarchy ( 655584 ) <> on Wednesday December 17, 2008 @08:43PM (#26153817) Journal

      I was semi-involved in this -- basically, Reiser4 wanted to make the filesystem pluggable, but in kernel-mode. The idea was that features would be implemented in the filesystem itself -- crypto, compression, files-of-files (for example, instead of suid utilities like passwd, just let me edit /etc/passwd/sanity), metadata-as-files (Unix permissions are a file, or things like foo.mp3/id3/genre)....

      Lots of cool ideas bouncing around, and most of them might work better as FUSE filesystems -- for example, there's no reason id3lib needs to be in the kernel.

      Some of them, it makes sense -- certainly for spinning disks, even moreso for external media, the media is so much slower than the CPU that compression makes sense, but you want to compress on flush, and not before. The part that was cool about that was, from the benchmarks they were getting, performance was actually better with compression turned on, because of how fast the algorithm is, how fast CPUs are, and how slow spinning disks are.

      But if you break down the "plug-in" concept, it was really horribly mis-named and mis-marketed -- it was just an API, like the pluggable IO schedulers were. It's really something that would probably go in the VFS layer -- something Hans had a really difficult time selling; according to his story, the first time he brought up his ideas, they told him to go put it inside his filesystem, not in the VFS, to try it out without making such drastic changes that would affect other filesystems. When he did that, and came back with the so-called "plugin" architecture, they told him that it should have been in the VFS, so that other filesystems could use it, and they refused to merge it.

      Looking at it now, it looks like most of these ideas, and some filesystems currently in the kernel, are better as FUSE filesystems. Better to keep the kernel smaller and more reliable, especially when the performance advantage is minimal -- FUSE will never be the bottleneck for sshfs, for example. Crypto works well enough at the block level (for full-disk crypto). And 20 years from now, we'll have computers so absurdly fast that no one will care about the performance hit of FUSE -- arguably, we're there already.

      But I do still wish that the compression, at least, would be tried, if those benchmarks have any truth to them.

      Anyway -- more directly, you would never have been able to write file-system customizations in Perl, unless Perl was put in the kernel, which would be an atrocity. However, you can write whole filesystems in Perl, Python, Ruby, or pretty much anything you want -- just use FUSE -- and nothing is stopping you from letting a real filesystem handle 90% of that.

  • by Animats ( 122034 ) on Wednesday December 17, 2008 @03:00PM (#26149991) Homepage

    These are mostly read-only implementations for dealing with archival data. They're not read/write, which is more work to implement and not that useful.

    QNX has had user-space file systems for decades. (It's a microkernel; almost everything is in user space.) Some users wrote file system implementations for weird file systems, like .zip files. Most of the modern QNX file system action is supporting various flash-based file systems and networked file systems.

  • I'm probably betraying my ignorance here, but the ability to implement filesystems in userspace was supposed to be one of the advantages of microkernel based operating systems. Given that Mac OS X is based on the Mach kernel, could this be better done as a Mach server (i.e. at the Mach layer) than in user space under the FreeBSD layer? I recognize that Darwin doesn't really take advantage of Mach as a microkernel in the way that it should, but surely there's *some* advantage to being built on Mach, right?
  • This is the one I'd most like to see. I've started using it extensively on my Linux boxes, and I like it much better than NFS or Samba. Big transfers require more CPU because of the encryption, but on WiFi transfer speeds are that high anyway, so it's not a bottleneck. Anyway, my wife's Mac is the one machine in the house it doesn't work on, and it would be great if she could use sshfs to mount stuff from the file server.

  • by bradbury ( 33372 ) <> on Wednesday December 17, 2008 @04:06PM (#26150841) Homepage

    > "One of their demos even has the old UNIX kernel compiled directly on the Mac
    > through the original PDP C compiler by somehow executing the PDP binaries on OS X!"

    Hmpfh... Circa 1978-79, Forrest Howard and I wrote a PDP-10 simulator that ran on a PDP-11/70 (a 36 bit machine on a 16 bit machine for those not educated in DEC hardware). It was used to recompile the DEC Fortran compiler which was written in Bliss-11. And the Bliss-11 compiler could only be run on a PDP-10. Lacking a PDP-10 (expensive pseudo-mainframe computers in those days) we simply wrote a simulator. It didn't run fast, as I recall the DEC Fortran compiler recompile took several weeks, but it did run.

    Reproducing a PDP-11 sumulator on modern hardware would be relatively trivial, though it would have been much easier on older Macs because it could be argued that the 680X0 architecture was a knockoff of the PDP-11 architecture. Though one could suppose that current era (non-680X0 or non-PowerPC) machines are fast enough that it is a noop. I think the PDP-11 had a 300 ns cycle time and current machines are ~10x faster. Any current machines could easily simulate a '70s era minicomputer (or even most mainframes).

  • I have a bunch of old floppies I'd like to access... B-)

  • I know this is off topic, but I really like the words 'Plethora' as well as 'thwart'.
    Unfortunately I haven't been able to make up a sentence with both plethora and thwart in them that make much sense.
    Something like: "I will thwart you and your plethora of new user space file systems."
    Back to work....

  • by master_p ( 608214 ) on Thursday December 18, 2008 @07:51AM (#26158631)

    Someone makes a filesystem in the 70s, and then 30 years later is still accessible...I don't think that's gonna be the case with Windows in 30 years in the future!

Anyone can hold the helm when the sea is calm. -- Publius Syrus