Slashdot Mirror
ZFS For Mac OS X Source Code Available
nezmar writes "Noel Dellofano, who is part of the ZFS development team at Apple, has a post on Mac OS Forge announcing a late Christmas gift: he is making available binaries and source code, plus instructions, of the ZFS filesystem for Mac OS X."
How stable is it, and how soon till I can get it on my Mac by default?
Reading their FAQ, it sounds like there are lot of niggles to fix yet - including assumptions in other parts of Mac OS. All in all it sounds like ZFS isn't ready for general use on the Mac just yet. Maybe Mac OS X 10.6 will ship with this by default?
I installed this last week, got it working. It's still very early beta, managed to crash my machine half a dozen times before deciding to wait a little. Remember to do zpool exports before you eject external hard drives. But yes, very promising technology. OS X has gone from having a wonky 1/0 implementation to having one of the better software raid systems available. Back to scoping out four and eight drive usb sata enclosures and cheap 500gb hard drives. ;-)
This reads like a nerd's unsubstantiated wet dream.
An absolutely, positively, amazing feature set. I can't wait until it's stable enough for production use. After 7 years of staying away from Apple products, I'm going back to the Mac.
Why are you letting these clowns ruin our country?
Since Apple employs Noel Dellofano, hosts Mac OS Forge, has incorporated the stable read-only bits in the latest Mac OS X Server and makes a slightly older build of the same code as the Mac OS Forge read/write version available on their developer web site, I think they approve.
I would imagine the kernel bits are significantly different, though mere availability of source, if not previously available, would likely help.
It's a shame that I'm gunshy with new (to the OS) filesystems. ZFS has so much to offer, but every time I try out a new filesystem, I end up with data loss, even ones that are supposedly new and wonderful and robust. (Even when ext3 was new but stable, I lost stuff on it.) I can't wait to hear lots of positive feedback on its stability and performance, so I can get up the nerve to try it.
Love many, trust a few, do harm to none.
Not that it really matters what Sun thinks about their F/OSS filesystem that anyone can download, modify or incorporate into their OS, but they are excited about Apple's adoption of ZFS, and have been contributing resources to the 'ZFS for OS X' project. It was widely rumored that ZFS would at least be an option in the shipping version of Leopard, if not the default filesystem. Someone over at Sun was even crowing about this a few months before Leopard was released.
I'd say Sun looks favorably upon this.
:q!
I have been using ZFS (on Solaris) for more than a year, both at work and at home, and I am following closely the latest developments. IMHO the best intro on ZFS is the official ZFS slides (36 pages): http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf
It's not a technical problem preventing linux usage so much as a political problem and a license problem. Unless this convinces those zealots that 1) FUSE isn't good enough and 2) CDDL is FREE, it won't do jack shit for linux.
Do you even lift?
These aren't the 'roids you're looking for.
ZFS is designed to perform writes asynchronously. If the write should be able to complete, it returns success and then goes off to do it. It's a different way of thinking about a filesystem. You need to do a "zpool export" or something before you can unplug a detachable disk to avoid the panic when you unplug it. That's not a bug. It's by design.
No it isn't. You're just misunderstanding the semantics of ZFS.
No it isn't. It's just not a filesystem that's suitable for the masses. Average users cannot understand or manage an advanced storage pool system like ZFS. They're better off with filesystems that make sense to them, like HFS+, ext2 or NTFS.
Shame on all the geeks for telling everyone that ZFS will solve all their problems. ZFS is great under certain circumstances. It does what it does very well, but it isn't a filesystem for the masses.
Just plain not reporting errors is a bug. ZFS asynchronous write semantics is intentional, although counter-intuitive, behaviour.
The sources has already been available under an open source license since ZFS came out.
Now, if we can only get it to talk to important things like NTFS, and Ext3, and Reiser...
I know it may be unheard of to those reading /., but Noel is a girl.
Huh? Music, movies, Office, and porn. And lots of web browsing (goes with the porn).
Do I want ZFS or not?
Well then, what does Paris Hilton think of this?
Paris Hilton? Think?
You should reformat with XFS.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Noel is a she. I met her last year soon after Apple hired her away from Sun.
I'm considering it, but your answer just says there is two different methodologies while claiming that one is better than the other. I am more wary of CDDL just as I am wary of Lucent's licence for Plan 9 (for sheer clever thinking, it would be my prefered OS -- discounting I haven't learnt how to use it effectively. Not as clever as the OS).
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
Nothing short of a complete redesign could have rescued WinFS. The design as it was was flawed from nearly the beginning.
It's a windows family tradition.
Suppose I ported ZFS to Linux (not that I could, just suppose) as a native kernel module, and published the source code. If then I used ZFS on Linux, and some others also grabbed the 'Linux ZFS' code, built it and used it. What laws if any would I be breaking? Who and under what grounds could sue me / Linux ZFS users?
then you need to mkfs, and if you run out of space you're screwed because you can't easily grow.
All of Linux's md raid modes are grow-able.
LVM2, XFS, and ext3 are all capable of not just expansion, but *online* expansion. With xfs, it's one command- xfs_grow -d. It automatically senses the new block device size and presto, you've got a larger file system.
BTDT two weeks ago when I added a drive to my RAID5 array, expanded the LVM2 physical volume, grew the logical volume, and then grew the XFS volume (I make the choice to run LVM2 on top of the array- I could have just as easily put XFS directly on the array device itself.) The only caveat is that you won't see the extra space until the resilvering is done.
I'm not saying it's equal to ZFS, but Linux's filesystems and volume management are a lot more capable than you're claiming, and everyone needs to calm down and realize that RAID is not ZFS, ZFS is not RAID, etc.
Please help metamoderate.
You're mistaken. ZFS RAID-Z is definitely "raid" -- in fact it's RAID without the RAID-5 write hole on non-specialized (no NVRAM in the controller) hardware. Contrary to what you said, you *can* easily go from a single drive to a pair of mirrored drives (see ZFS admin guide, p. 59) or a RAID-Z (p. 60). The only real limitation is you cannot add an additional disk to an existing RAID-Z configuration, the idea right now being that you'll add another set of disks in RAID-Z as a top-level vdev. This is not optimal for a lot of scenarios but they're working on it. ZFS mirrored configurations are more flexible.
The data integrity advantages of ZFS over traditional RAID-4 and RAID-5 are hard to argue with... it validates the entire input-output path.
The design of ZFS is intended to ensure that the data on the disk is _always_ a valid file system. If a system panics when a ZFS file system is unexpectedly removed, that is a different issue.
Then, of course, checksumming everything does wonders to protect against bit rot and flaky cables.
It's not a question of whether people thing CDDL is Free or not. There are "zealots" like Stallman who think that both GPL v2 and GPL v3 are free. But he would be the first to say you can't include GPL v3 code, like a future relicensed version of the Solaris kernel, in GPL v2 code, like the Linux kernel.
And I think most people will agree with you that Fuse isn't good enough. But at the moment, there are only two options: complete reimplementation from the ground up, and Fuse. Fuse is easiest.
Look out!
Have you tried NTFS-3G? It really is very stable, no doubt due to the exhaustive testing regime on every release - see http://www.ntfs-3g.org/quality.html - and is used by default in most Linux distros. It's a different codebase to the older Linux-NTFS and Captive NTFS projects, and has reasonably good performance.
Since ZFS is new, I don't think your scenario applies, and it's not intended for DVD/CD use.
Actually, I see no reason why FUSE wouldn't be perfectly acceptable for zfs - at least until people start seriously considering zfs for root filesystems. FUSE is fast enough, stable enough, and flexible enough. We don't have X in the kernel, I don't see that we _need_ to have the filesystem in the kernel either.
From the FAQ: Downloading music via iTunes onto a ZFS target volume does not work yet. iTunes will complain it can't write to the volume. So there seems to be a link between iTunes and HFS+? Sounds like someone needs to do some reverse engineering...
Quisque verborum suorum optimus interpres...
There is no decent vast repositories either for Solaris which exist on major distributions (like Ubuntu) while there are alternative repositories/package management systems available for Solaris. Solaris just does not have the vast amounts of software that are available on the majority of Linux distributions. A common theme I see is that it doesn't even have simple ham radio software that I find even on smaller Linux distributions.
That said, it is possible to create a virtual machine in Solaris which runs a Linux distribution of your choice (Solaris' kernel supports this), but in my experience, it seems slower than running the Linux distribution directly on the system and if you're getting ZFS for performance -- I don't think this sort of usage will help performance significantly.
One other thing I might add, Solaris is not that easy to use compared to Linux distributions. There is no equivalent to even harddrake/restricted manager/YasT/systemsettings when it comes to configuring hardware support.
Change is certain; progress is not obligatory.
UFS might not have all the bells and whistles of ZFS, but it's still been the most reliable and robust file system I've used in the past 25 years. It's got decades of work on making it stable and solid, and thanks to the tools available to work with it and the redundancy in the format I've even been able to recover data from UFS partitions that had been partially reformatted.
HFS? I've had HFS partitions get corrupted just be letting them get too full. That's just nuts.
ZFS? Sun says ZFS doesn't need file system check and repair tools, it can't fail. That's what DEC said about AdvFS, than then later on came up with salvage tools to pull data out of a damaged AdvFS file system. That's what the Linux folks used to say about Reiser FS, too. Even before the Hans Reiser incident it had become clear that it wasn't true, and I've got no reason to assume that ZFS will be any better, not over the long term.
The only journalled file system I've found that has come anywhere near that goal has been Network Appliance's, and they have complete control over the hardware and software and no third-party applications and drivers running on the hardware. And, of course, few places have very many NetApps (we certainly never had more than 4 at a time) so I can't say that the apparent stability of our boxes isn't due to the fact that we simply never had many of them...
Apple refreshed UFS for Panther, bringing in SoftUpdates to give it the performance advantages of journalling, then dropped it.
Apple has created layers that run over network file systems that implement almost all of the application-visible differences between HFS and remote CIFS and NFS shares, but you can't take full advantage of these for local UFS file systems. Why not? Don't ask me, ask Apple.
I blame corporate ADHD.