Slashdot Log In
Plethora of New User Space Filesystems For Mac OS X
Posted by
CmdrTaco
on Wed Dec 17, 2008 12:46 PM
from the because-you-can dept.
from the because-you-can dept.
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!"
Related Stories
Firehose:Gazillion new user space filesystems for Mac OS X by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Looking forward to this! (Score:4, Interesting)
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.
Sounds great. (Score:5, Interesting)
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)
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.
Parent
Re:Sounds great. (Score:4, Informative)
Parent
Re: (Score:3, Informative)
ext3 (Score:5, Insightful)
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.
A Plethora? (Score:5, Funny)
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?
These are mostly read-only (Score:4, Informative)
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.
Real programmers do bigger on smaller (Score:4, Interesting)
> "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).
Re:News? (Score:5, Insightful)
Because slashdot isn't a public service announcement system and macfuse is more interesting?
Parent
Re:News? (Score:4, Insightful)
I'd say that what's interesting and what's not interesting is all a matter of opinion, but it stands to reason that if you own a Mac and would be interested in this software, you would also be interested in knowing that a recently released update from Apple is causing major system trouble.
Parent
Re:News? (Score:5, Funny)
Parent
Re:News? (Score:5, Insightful)
Parent
Because... (Score:4, Insightful)
Some users installing third party apps that modify their system files, and then apply updates over them have issues is hardly newsworthy.
Parent
Re:Because... (Score:5, Funny)
Riiiiiight... Because a Linux-heavy audience would never even consider violating the sanctity of those spoooooky "system files" of which you speak...
Parent
Sure (Score:5, Insightful)
You most certainly can if you want to. But if you have system files A and B and you modify B and later system update modifies A to call something in B that you changed the behavior of, then don't blame the system update.
That's all I'm saying.
Parent
Re:Because... (Score:4, Insightful)
Try that with Ubuntu, upgrade, and then see what happens... similar :) I know, I've been there...
Parent
Re:News? (Score:5, Funny)
Macs are gay.
Yeah. My macs are gay. But I talked to them, I explained I am hetero, and they never molested me - they never did anything to hurt my feelings. I am tolerant, but not interested in gay relationships. My computers understood that.
Not that I would ever be interested in having sex with a computer anyway...
Roberto
Parent
Re:News? (Score:5, Funny)
Not that I would ever be interested in having sex with a computer anyway...
Well, SOMEBODY'S in the minority on Slashdot...
Parent
Re:ext2 on Mac (Score:4, Insightful)
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.
Parent
Re:So what? (Score:5, Insightful)
External hard drives, for one. I have some external drives I use on Linux boxes for various things. All of these boxes are up in an air conditioned server room. On occasion I need to get one file off onto my workstation, which is a Mac. Currently I have to walk it up to server room, connect it up, go back down, shell into the machine and mount it (if it's not an automounted drive), then somehow get the file out of the linux box to my Mac (scp or something). If I could just mount it on my workstation, it would save a lot of time.
Additionally, there are occasions where a recovery process needs to be run on a bad drive. The same procedure applies. It's mainly a convenience thing, but it would make the Mac into a much more useful tool for admins. I can definitely see the usefulness for FAT/NTFS in a desktop support environment.
Naturally you can always comment "Why use a Mac in the first place when you could have a linux desktop?" but I would reply that I don't have a choice, the CEO only buys Macs for workstations. So I have to use what I've got. This would make my life easier.
Parent
Re:So what? (Score:4, Interesting)
Naturally you can always comment "Why use a Mac in the first place when you could have a linux desktop?" but I would reply that I don't have a choice, the CEO only buys Macs for workstations. So I have to use what I've got. This would make my life easier.
And Macs don't run linux?
Parent
Re:Every filesystem! Except the ones that matter.. (Score:5, Informative)
No, NTFS has support via NTFS3G. The other popular file system, FAT, is already supported natively.
Parent
Re:cool, now lets make in run on linux (Score:4, Funny)
You're supposed to flaimebait anonymously.
Parent
Re:Reiser 4 (Score:4, Informative)
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.
Parent