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."
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.
Consider my comment some of that.
I've had no problems with 5T+ datasets, and we even get about a 10-20% performance boost out of it compared to UFS.
snapshotting & all those neat features work totally as expected.
Only minor issue I see is that a zfs send is single threaded, so you cant parralellize it over multiple processes easily.
a readonly version is included with leopard:
...
sh-3.2# zfs
Read-Only ZFS Implementation
missing command
usage: zfs command args
Do you even lift?
These aren't the 'roids you're looking for.
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.
I've been running ZFS on my home Mac server since the old developer seed. It's generally stable as long as you disable Spotlight indexing on the volume (it's not supported yet). Everything on the command line works, as does accessing the ZFS pool over AFS. It's *very* easy to set up btw, much easier than setting up a RAID in Linux. There were issues deleting files from the Finder in the last release; I haven't installed the 102A release yet. Still, if you're just using it for a server volume, you'll probably be happy with it.
I know it may be unheard of to those reading /., but Noel is a girl.
Or more to the point, OpenSolaris... because that's where it came from
You should reformat with XFS.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
You forgot:
For LVM, one has to partition the disks first. If you're giving the whole disk to ZFS, just use something like "zpool create pool raidz c5t6d0 c5t6d1 c5t6d2 c5t6d3" (that's straight from memory - don't hold me to the exact syntax...). ZFS will partition the disks for you.
One less thing to worry about with ZFS.
Noel is a she. I met her last year soon after Apple hired her away from Sun.
It's so that you can bring a ZFS volume to any old Mac running Leopard, plug it in, and read data off it, without having to install any extra (currently beta) software.
This is also why, when you create a ZFS pool using the read/write drivers, it defaults to creating a pool with ZFS version 6 on disk, so that it's compatible with the version of ZFS shipping with Leopard. (You run "zfs update" to transform your pool to the most recent on disk version if this kind of compatibility isn't an issue for you.)
BTW, Leopard also reads from BSD and Solaris-created ZFS drives just fine.
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.
"what good is a file system if you can't write to it?"
I could say the same of NTFS. After throwing in the towel with regard to Windows as a base OS, I have years of accumulated data on NTFS volumes spread across a small pile of drives. Linux support for NTFS is still a little shaky. But with read-only access to NTFS, I can throw those old desktop or laptop drives into an enclosure, connect it, and either pull all the data over to a writable volume for ongoing work (and perhaps dispose of the old drive), or pick out individual pieces of data I want without worry of corrupting the volume.
How does this apply to ZFS? Not sure, since "piles of old data" isn't a likely scenario on ZFS. But I can imagine accessing shared NAS/SAN ZFS volumes with only one system managing dynamic allocation... or perhaps ZFS in place of ISO9660 to speed up large software installations?
I think not...(*poof*)
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.
Here's a link explaining the parent for all you c|net "reporters" and NYT technology stringers who read slashdot. You know who you are.
Don't blame me, I voted for Baltar.
For LVM, one has to partition the disks first.
No you don't, LVM Physical Volumes can be initialised straight onto whole unpartitioned disks (/dev/sda).
You should watch these. (thanks andrewg for links)
For anyone who has not seen the ZFS demonstration videos by Bill Moore you must watch the link.
High Bandwidth versions - http://www.sun.com/software/media/real/zfs_learningcenter/high_band...
Low Bandwidth versions - http://www.sun.com/software/media/real/zfs_learningcenter/low_bandw...
Also general info here:
- http://www.sun.com/software/solaris/ds/zfs.jsp
- http://www.sun.com/software/solaris/zfs_learning_center.jsp
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.
filesystem fanboys?
I have setup a few raid setups (LVM, and ZFS, and hardware based.)
where ZFS is nice, their is a nice documented one way to do it. It's biggest advantage (for me) are a single interface for turning on/off encryption, compression, and file system snapshots. Things this does for you for example, is you can turn on compression for a entire volume, or directory within the filesystem but you don't have to take it offline ever, because it will compress new files only (to start), and you can then walk through the rest as CPU allows...
You do have all these options for LVM, with ext3, but in the truly linux tradition, their are many, many different ways to do the same thing. So if you don't want to spend hours researching the how's and whys you easily end up creating more work for yourself. But I am sure if you do all the research you can create a more efficient solution. But you'll also end up with many different interfaces (that has advantages too). For example I am replacing a RHEL hardware raid with Solaris zfs raid now. To admin the RHEL solution, I use LVM to admin allocations, use ext3 to look for file system corruption, use the Raid manager program to add/remove/grow drives, and NFS to export partitions/permisions, and various webmin plugins for backups restores, file versions. All of these are now within the zfstools on solaris.
I've been running the 7.0 branch since about October '07, and I've been using ZFS. Granted, it's my home machine, but it's my primary workstation and I *need* this machine to bring home the bacon, working via home office and all. While I don't use it for important data, the file systems I chose were intentional in order to beat it up a lot: /usr/src, /usr/obj, and /usr/ports -- that's where all of the kernel/userlad/ports compiles take place (at least by default). Tons of reads/writes/delete since I update my ports and source trees almost daily. Never once have I had a problem. On a whim, I ran a zpool status once and found a corruption error on /usr/obj, but I never noticed because it just kept on chugging along. Not that /usr/obj is a terribly critical directory, one which I nuke on a regular basis to ensure a pristine system rebuild. Still, I ran a "zpool scrub" on it live, and it fixed the problem w/o ever going offline.
Not only that, I also use the built-in compression (gzip9) on /usr/src and /usr/ports and my machine is amd64. The former really taxes the system, and the latter platform seems to lag slightly behind i386. Sometimes my machine has quick freezes when the ZFS file systems are being beat up, but my machine is only a 2.0GHz w/ 1GB of memory. For pre-release software, FreeBSD 7.0 really kicks some ass.
Of course, anecdotes are not synonymous with data. ZFS obviously has some issues. But then again, so did reiserfs and ext3 when they were first cast into the mainstream kernel and distros. Sure, the BSD userbase with ZFS is *much* smaller than those of Linux, but I expect ZFS will shine in short order.
Method of processing duck feet
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.