Slashdot Mirror
Plethora of New User Space Filesystems For Mac OS X
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!"
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.
It doesn't mean much now, it's built for the future.
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.
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.
-- i am jack's amusing sig file
Because slashdot isn't a public service announcement system and macfuse is more interesting?
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.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Some users installing third party apps that modify their system files, and then apply updates over them have issues is hardly newsworthy.
As the island of our knowledge grows, so does the shore of our ignorance.
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.
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.
Cool! Amazing Toys.
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.
As the island of our knowledge grows, so does the shore of our ignorance.
No, NTFS has support via NTFS3G. The other popular file system, FAT, is already supported natively.
You're supposed to flaimebait anonymously.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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?
From my impression an Apple update causing major system trouble really isn't news.
// MD_Update(&m,buf,j);
you mean BARELY causing? I am sorry but a hundred or so postings when there are over a million OS 10.5 users out there is NOT in my mind major trouble.
"Slashdot, where telling the truth is overrated but lying is insightful."
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.
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?
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
Not that I would ever be interested in having sex with a computer anyway...
Well, SOMEBODY'S in the minority on Slashdot...
> "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 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.
Don't thank God, thank a doctor!
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 disconnect. Yes, while it's running NTFS-3G.
However, not once in the last 12 months has my NTFS filesystem become corrupted. Not once.