Apple Removes Nearly All Reference To ZFS

Roskolnikov writes "Apple has apparently decided that ZFS isn't really ready for prime time. We've been discussing Apple/ZFS rumors, denials, and sightings for some years now. Currently a search on Apple's site for ZFS yields only two hits, one of them probably an oversight in the ZFS-cleansing program and the other a reference to open source. Contrast this with an item from the Google cache regarding ZFS and Snow Leopard. Apple has done this kind of disappearing act in the past, but I was really hoping that this was one feature promise they would keep. I certainly hope this isn't the first foot in the grave for ZFS on OS X."

Comments

Well fuck it, we're going to 128 bits

[QuantumG]

cross-meme joke completed.

Re:Well fuck it, we're going to 128 bits

[greg1104]

WOOSH!

Larry effect again?

[G3ckoG33k]

Could this be a Larry effect?

Re:Larry effect again?

[rsmith-mac]

Larry Ellison, the Oracle CEO. Oracle just recently purchased Sun (makers of ZFS), so the OP is postulating whether Apple pulling ZFS is a product of Cisco not working on/opening up ZFS to Apple like Sun did.

Re:Larry effect again?

[ildon]

I'm thinking Balki effect.

Re:Larry effect again?

[mrsteveman1]

No, Google "2 CEOs, 1 filesystem".

Re:Larry effect again?

[Anonymous Coward]

One
Raging
Asshole
Called
Larry
Ellison

Re:Larry effect again?

[ThePhilips]

It's actually more interesting than that.

Oracle currently sponsoring development of Btrfs for Linux, which is equivalent to recently acquired ZFS. I wonder if that played any role.

P.S. Though my personal opinion is more pragmatical. ZFS doesn't seem to be extensible and obviously doesn't support all featlets of HFS/HFS+ (streams, aliases, case insensitivity) which are required for Mac OS and its applications. I guess that should have been a major bummer. Meaning that even if Apple would add ZFS support, it would very likely have different name and it would be incompatible with Sun's ZFS.

Re:Larry effect again?

[AttilaSz]

It's widely known that Steve Jobs and Larry Ellison are good friends, see this from http://en.wikipedia.org/wiki/Larry_Ellison

"On 18 December 2003, Ellison married Melanie Craft, a romance novelist, at his Woodside estate. His friend Steve Jobs, Apple, Inc's CEO, was the official wedding photographer."

So, no, Larry's company becoming ZFS owner ain't the reason Steve's company would drop it.

Re:Larry effect again?

[larry bagina]

OS X supports UFS, which doesn't have those features either. And ZFS does have extended attributes support.

Re:Larry effect again?

[zsau]

Call me dumb, but I don't get it. The only thing I find there is references to your own post.

Re:Larry effect again?

[countach]

ZFS has xattrs which are close enough to streams. Aliases aren't part of the FS in HFS either. Case insensitivity is more part of the kernel's interpretation than the FS per se.

The one thing ZFS won't have is hard linked directories, which is needed for time machine.

One thing I heard is that ZFS actually has to copy an entire file if you even change one byte. That's got to be bad for many applications. It seems hard to believe, but that's what I read. Can anyone confirm?

Re:Larry effect again?

[b96miata]

Copy-on-write is at the block level, if I'm not mistaken, and given that data has to be written in blocks to block devices anyway it's not that big of a deal.

Re:Larry effect again?

[jonadab]

Just because the CEOs are friends doesn't *necessarily* preclude that the companies could be at odds from a business perspective. I'm not aware of any particular reason to think Apple pulled away from ZFS because of anything specifically to do with Sun, but if there _were_ a reason to believe that, I wouldn't dismiss it just because the CEOs are friends.

Re:Larry effect again?

[v1]

http://lmgtfy.com/?q=recursion

Re:Larry effect again?

[rackserverdeals]

I'm thinking they didn't put enough resources into ZFS?

From http://zfs.macosforge.org/trac/wiki

Where is .zfs? I can't find my snapshots

Your snapshots are there and working correctly there's just no .zfs directory yet since I'm still porting that functionality. You can use 'zfs clone' to work around this for now if you'd like to browse your snapshots. You can see an example and get more info off of the Known Issues and Features page

Even the BSD folks have more than one developer working on the ZFS BSD port. Although I must commend him for not using "we" to make himself sound bigger than he is.

We thank you for reading this comment.

Re:Larry effect again?

[saleenS281]

That isn't at all true. Copy-on-write works at the block level. ZFS doesn't "copy the entire file", rather than overwrite an existing block, it allocates a new one, and marks the old one for deletion by a clean-up process later on.

Re:Larry effect again?

[saleenS281]

I'm surprised those two ego's can both fit in the same room. Was it an outdoor wedding??

Re:Larry effect again?

[AttilaSz]

That's true. All I said is that Apple wouldn't drop ZFS just because it became Larry Ellison's property (which is what OP suggested). There might be other legitimate business reasons to drop it though. I personally suspect Apple engineers hit a technical problem that'd jeopardize Snow Leopard deadline, and had to make a no-go decision. Or maybe its legal has problems with licensing, although CDDL shouldn't be a problem, so that's less likely IMHO.

Re:Larry effect again?

[xZgf6xHx2uhoAj9D]

Wouldn't they just use ZFS snapshots to do Time Machine? Dealing with hard linked directories is awfully slow (evidenced by how slow my Time Machine back-ups are).

Re:Larry effect again?

[Nevyn]

However the references to that block, then have to be changed (and the references to them, all the way up the tree). But in the real world applications don't write one byte at a time.

Re:Larry effect again?

[Score Whore]

Control of case sensitivity is built into ZFS:

-bash-3.2$ zfs get 2>&1 | grep case
                casesensitivity NO YES sensitive | insensitive | mixed

They included it so that CIFS could behave as expected.

Re:Larry effect again?

[afidel]

Actually it doesn't mark it for deletion because the block may still be part of a snapshots filesystem bitmap. In this way it's quite similar to WAFL from Netapp. What the cleanup process does is checks the currently allocated block bitmap to all of other bitmaps and frees any allocated blocks that aren't in use by anything.

Re:Larry effect again?

[pyite]

The one thing ZFS won't have is hard linked directories, which is needed for time machine.

ZFS out-time-machines Time Machine. Very good snapshots are available by default. OpenSolaris implements something known as Time Slider which provides similar features. Really, Time Machine would have been easier to implement in the first place if they switched to ZFS with Leopard.

Re:Larry effect again?

[corprew]

'Larry' is often used metonymously for Oracle's corporate direction, even when Larry isn't involved directly, just as 'Steve' is for Apple.

Re:Larry effect again?

[willy_me]

I always thought that the problem with MacOS X and ZFS was with removable devices. ZFS does not play well with devices that could be removed without first notifying the system. When it comes to desktop / notebook computers, ZFS just doesn't offer many advantages.

Re:Larry effect again?

[sidb]

Time Machine serves two purposes at once: snapshots and backup. Having snapshots available doesn't help when the disk dies or gets corrupted. I suppose you could still copy everything to another disk and then use the ZFS snapshot features there, instead of using HFS hardlinks, but copying to another physical disk still needs to be part of the process.

Re:Larry effect again?

[IntlHarvester]

Apple didn't really "support" UFS - many applications were incompatible with UFS, and 10.5 can't boot from it.

Re:Larry effect again?

[ToasterMonkey]

You can easily import/export ZFS snapshots with zfs send|receive.

zfs send snapshot | ssh other zfs receive pool

Or send to a regular file...

Re:Larry effect again?

[am 2k]

Yes, but that way you're sending the whole disk's content every single time instead of a delta. That's no good if you're doing it once per hour (which is what Time Machine does).

I looked into zfs backup mechanisms for my ZFS-based NAS. I settled with rsync, since it seems that it's the only solution that actually does what I need. It's still a lot worse than Time Machine, because it actually has to look at every single file to compare it (takes about 3 days to do a full backup over gigabit network now, where Time Machine takes 5 minutes).

Re:Larry effect again?

[ulzeraj]

Overall, the operating system and its out-of-the-box contents work fine with case sensitiveness. There are however, a ton of applications that refuse to work with it or run with some problems. World of Warcraft is an example of that. I had to create a disk image formated as HFS+ case insensitive and install it unto it to make it work. Maybe OS X programmers are a bunch of lazy bitches without self respect.

Re:Larry effect again?

[shokker]

Incremental zfs send works just fine:

zfs send -i master/data@1 master/data@2 | zfs receive slave/data

That way you just send the differences since snapshot "1".

Re:Larry effect again?

[am 2k]

But with this method, you have to retain all backups. If you'll ever happen to run out of storage on the backup volume you're SOL, since you can't just delete individual snapshots.

That's not an issue with Time Machine.

Death knell

[siloko]

I certainly hope this isn't the first foot in the grave for ZFS on OSX.

More like the last nail in the coffin . . .

Re:Death knell

[Macrat]

Or it's not ready for a consumer OS yet.

Re:Death knell

[udippel]

More like the last nail in the coffin . . .

Which is what I hope. Having tried forth and back over the last years, trying to convince myself, that it would fulfill its promises (and it promises a lot! and all beautiful things) one day or another.
It simply didn't. Which is a shame, since if it did, ZFS would be last file system mankind would have ever needed.
But even in 2009, it suffers from serious problems, just read the ZFS list in OpenSolaris. Basic things, that is.
Like boot corruption; like unusable system, if you pull the power, and pull the power again while it is restarting; Like slowness under specific conditions; like rendering the file system unbootable, reproducibly, when using a specific setup of snapshots.
The latter, not addressed on the mailing list, killed our interest immediately.
Not to forget some arrogance of the Sun engineers when it turned out that you cannot simply unplug a USB-drive. And it won't be enough, to umount it, neither. If you want the data to be there, sure, after the removal, you have to export the drive. Now tell this to Aunt Tilly. Or me, when I stumble over a USB-cable and out it is. And my data, as confirmed on the mailing list, potentially gone forever; with, confirmed, no tool available for recovery.

My last hope for it, had been that the engineers at Apple were able to give it the life-line needed to provide reliable Time-Machines (the snapshots of ZFS are just perfect therefore), but obviously, they have given up just as well.

I bet that something like ZFS will resurrect, one day or another. It simply has to. But ZFS as of today is more like Leonardo's drawings of a copter, compared to an Apache.

Re:Death knell

[Anonymous Coward]

What ZFS does have that typical Apple Consumers would like to see it on desktops and not just on servers?

Almost every ZFS oriented discussion, there just comes one point up. ZFS is not miracle what is not possible to gain already with other kind setup with RAID and other filesystem.

Re:Death knell

[KonoWatakushi]

This is almost entirely nonsense. I have been following the zfs-discuss list for years, and almost no one has lost data. There have been a few bugs which could in rare cases render your data inaccessible, but they almost always have workarounds, and do get fixed.

The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved, or more rarely the lack of ECC ram. It is true that ZFS is less tolerant of bad hardware. Note, faulty good hardware is not considered bad; that is reserved for garbage which (for instance) lies to the OS about flushing the disk cache. With such hardware, it is impossible for any filesystem to function reliably.

USB and Firewire bridges are notorious for this. If you care about your data, you should run the other way if you happen upon one. ZFS works great on good hardware though. With directly attached disks and ECC ram, there is no cause for concern.

Re:Death knell

[speedtux]

The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved, or more rarely the lack of ECC ram. It is true that ZFS is less tolerant of bad hardware.

What good is a fault tolerant file system if it isn't tolerant of faults?

With such hardware, it is impossible for any filesystem to function reliably.

Quite incorrect.

USB and Firewire bridges are notorious for this. If you care about your data, you should run the other way if you happen upon one.

Well, golly, those only happen to be the way 99.999% of Apple's customers attach exernal drives, not to mention 99.9% of all of the rest of the world.

Re:Death knell

[ishobo]

We run ZFS on every FreeBSD server and a few desktops. Mostly 64bit. It requires tuning. I have a laptop with 1GB running FreeBSD and ZFS has been rock solid. The instant volume and snapshots creation has me hooked. I could never go back. I wish ZFS existed for Windows.

ZFS development is not over; it is still being actively maintained.

Re:Death knell

[ishobo]

Windows and Solaris fall into the first category, UNIX and Linux into the second.

Are you sure you do not want to correct that statement?

Re:Death knell

[udippel]

I have been following the zfs-discuss list for years, and almost no one has lost data.

That's not good enough for the likes like me.
For the rest of your post, I am simply too lazy to prove you wrong. For a beer each I could fiddle out those that were confirmed to lead to data loss, including unrecoverable data loss, as I mentioned in my post.
But I won't do this (except for that beer each), because you know that best yourself:
The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved, or more rarely the lack of ECC ram
Because this is exactly, word for word, the usual excuse given in the mailing list.
And I didn't add the one in my original post, when it was 'confirmed' that you need RAID if your data are valuable to you; and now, read this in bold: irrespective of hardware failure. I for one accept the need for RAID, in case of a hard disk really and effectively dying. Not for manhandling the data. Read the postings carefully.

Of course, the other person answering your flawed arguments about 'crap hardware' is right to the point: What good is a fault tolerant file system if it isn't tolerant of faults?
May I remind you, the premise and promise of ZFS was the atomic write, the always consistent state on the drive. I do think and believe this is true, and all blocks are either written and confirmed or just not. As far as I can make out, the problem has only been shifted: to the problem of metadata. Again, refer to the mailing list. Those exist in four-fold. Why? It seems the consistency of blocks on the drive being guaranteed, the layer of actually having the links to those correct data is more vulnerable. Think of a pool: if you jank the structure of a pool by janking a USB, you have 100% correct data (contrary to any other file system, I agree), but alas no more structured access to reassemble them (compared to inodes).

(The mods opting for 'informative' of your post obviously don't read the ZFS mailing list, and nobody blames them.)

Re:Death knell

[KonoWatakushi]

What good is a fault tolerant file system if it isn't tolerant of faults?

This is not about faults; ZFS handles those fine. This is about hardware which behaves badly.

You should not talk so authoritatively when you are so obviously ignorant of the subject. What you are implying, is that a filesystem does not care about the ordering of writes, and that is absolutely absurd. The ordering of writes is more critical for copy on write filesystems like ZFS, but in neither case is your data safe on bad hardware.

Like you point out, there is lot of bad hardware out there. What you overlook is that existing filesystems have no facilities to catch, much less correct such errors or corruption; that is why it is called silent data corruption. Even filesystems like HFS+ only journal metadata, so this is a lot more common than you realize.

ZFS can be improved on misbehaving hardware, but that still won't fix bad hardware. Those improvements will only allow the possibility to recover to a consistent state, but data will still be lost.

Re:Death knell

[ThePhilips]

Of course, the other person answering your flawed arguments about 'crap hardware' is right to the point: What good is a fault tolerant file system if it isn't tolerant of faults?

Or in layman's terms: if shit happens, system shouldn't help to spread it, but to localize it.

(The mods opting for 'informative' of your post obviously don't read the ZFS mailing list, and nobody blames them.)

What you describe is a standard problem faced by all journaling and/or distributed file systems. Or for that matter any distributed ("shared data") system. You simply cannot guarantee anything (efficiently) when many asynchronous agents are involved. And it all depends where would designers cut the compromise with inefficiency (force sync of all the agents).

Judging that it took Veritas a decade to make such system (at least from reading their 5.0 papers I get the impression), I think ZFS needs much much more time to mature.

Re:Death knell

[wereHamster]

Every disk will corrupt eventually, it's just a matter of time. Not even the best hardware will help you there. So the question is, how well does the filesystem catch these errors and correct them. It turns out, ZFS is really bad at this, as it can get into a state where you can't even import the pool (where zpool either stops with an error and in worse cases causes a kernel panic). There have been numerous bug reports on the zfs mailing list and the opensolaris bug tracker. So far nobody seems interesting in fixing those. My pool got corrupted in such way. I had to manually poke around the filesystem and invalidate metadata until zpool was able to import the pool. Something that a 'fsck' could have easily done, but Sun refuses to create such tool because, according to them, ZFS is robust enough. All credits go to this guy who had the idea to invalidate the uberblocks directly on the disk: http://opensolaris.org/jive/message.jspa?messageID=318457#318457

Re:Death knell

[Bandman]

>The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved

Ah, this must be the arrogance that the grandparent mentioned.

>USB and Firewire bridges are notorious for this. If you care about your data, you should run the other way if you happen upon one.

If I have to use a USB disk, I should expect to lose my data? What world do you live in?

Just call it an 'enterprise only' filesystem and people wouldn't get so riled about it. It's when it's compared to sliced bread that I get sick of hearing about it.

"On a redundant controller SAN with battery backups attached to independent power sources addressed by a fully redundant server with ECC memory, ZFS is a good filesystem". That's all you have to say.

Re:Death knell

[uglyduckling]

I've been struggling, really, to read, your sentences, with that many commas.

Sorry, sounds a bit harsh and trollish but someone had to say it and might just save you driving someone mad in the future ;-).

Re:Death knell

[JoeMerchant]

In 2006 I was given a MacBook Pro to work with... it had been over 10 years since I computed on the fruity side and I decided to trust that Apple had "done the right things" with the features they included. One feature of interest was their "FileVault" which gave a "here, try this:" howto on encrypting your home directory. I thought with all the "just works" hype that surely Apple would have made such a thing secure and reliable... it wasn't 2 weeks before my MacBook Pro was useless, had to re-install OS-X from DVD, as confirmed by an Apple Tech support guy who actually sounded like he knew what he was talking about... see, in 2006 the MacBook Pro wouldn't always shut down cleanly, so a hard power-off was required every couple of days... this hard power off glitched the FileVault, rendering everything in it (my one and only home directory on the system), inaccessible, and therefore the system unbootable past the login prompt.

Lessons learned:

Even today, encrypting files necessary to boot the system is a bad idea - the promises of ZFS would cure this, but only if they are true.
Always create a back-up account, or three, so you don't have to brain-wipe the system when your primary account goes dead (which mine never has since then, of course it is also not encrypted anymore).
"Just Works" is fanboi speak for "I really like my shiny computer and I'll say anything to make you think it's better than yours.", OS-X is on-par with other modern OSs in terms of reliability and usability, at least in my experience of the last 3 years, they (OS-X, Vista, ubuntu) each have strengths and weaknesses, but overall, OS-X isn't a shining star in any area that matters to me.

If ZFS were "ready for prime time" I expect that it would be in ubuntu already. If I were in corporate cost cutting strategy at Apple development, I'd say "let the Linux world sort that one out" and pick it back up if/when it is ready for prime time. Because, if Apple sorts it out on their own nickel, they'll only have the geek-head advantage for a little less than a year before useful ZFS is picked up by the Linux world, and I doubt that one year of geek-head advantage translates into enough extra shiny boxes sold to cover the (apparently high and growing) cost of ZFS development.

Re:Death knell

[asaul]

Name one filesystem that can deal with silent data corruption - sure in a lot of cases they just keep going because they have no way of knowing the data they just read from disk contained half of a corrupted write. Just because years of trial and error has made fsck tools to *attempt* repairs post-mortem does not mean ZFS is doing something wrong when it tells you "your data is fucked, now".

ZFS works fine on cheap hardware too, I have seen some brilliant performance figures on cheap home SATA setups. I would support the ECC statement though from personal experience. Its no good having any sort of decent storage setup when single bit flips in memory crap on your data. With UFS I might not have noticed until it got bad enough to completely stuff the filesystem, but with ZFS I picked it up straight away before I lost any more files.

Re:Death knell

[Znork]

Shh. Don't mention lack of ECC RAM, Sun products and crap hardware in the same comment.

It makes some of us oldtimers recall various versions of the Sparc 'cosmic rays are crashing your server' ULTRA II, and the joy of having every piece of software and hardware in your Sun servers replaced and having them crash anyway.

Re:Death knell

[jbolden]

What ZFS does have that typical Apple Consumers would like to see it on desktops and not just on servers?

Snapshots. Which with heavy use of rsync (TimeMachine) allow for very large files to be versioned without having to save the file over and over and over again. Also file saves will become much faster.

Variable block sizes so that different directories (parts of the OS) can be tuned differently.

More inodes for disks over 1TB. As disk sizes start hitting say 100TB HFS is going to be in serious trouble.

   

Re:Death knell

[countach]

Well here's the thing. Almost all Macs rely on FireWire and USB for storage beyond the builtin disk.

Re:Death knell

[toby]

What ZFS does have that typical Apple Consumers would like to see it on desktops

Pretty much all of it applies equally to consumer systems.

ZFS is not miracle what is not possible to gain already with other kind setup with RAID and other filesystem

You need to study ZFS more, as you clearly know little about it. Almost no RAID systems can do what ZFS does. Hints: end to end checksumming; self-healing; copy on write; ...

Hint: The extra capability largely comes from integrating both the "filesystem" and "volume manager" layers, which are separate modules in traditional configurations. Calling ZFS a "filesystem" seems to mislead a lot of people that it can be compared to other "filesystems"; and the fact that ZFS implements RAID-like redundancy leads people to think that it can be compared to other "RAID" systems. Sure, it can be compared, but conventional systems will generally lose (notably in data integrity, but also in performance, manageability, etc).

Re:Death knell

[Sancho]

I think that other people are talking about what are arguably bugs in the disk's firmware. The disk will report back that data has been written, but in reality, it's only in the cache. I only glanced at the forum postings in your link, but I didn't see any mention of what hardware was being used. It's certainly possible that they were using good hardware--but the poster's note that they had accidentally halted makes me wonder if his problems were related to using a poorly implemented drive.

Regardless, behavior like this can cause metadata corruption in filesystems which are designed with consistency in mind--and I think that's what happens with ZFS. The developers apparently don't want to code a utility to recover from failures from these poorly or incorrectly designed hard drives. And it makes sense--Sun is ultimately a hardware company, and they want to sell you the good stuff. Why work around a bad firmware when they can sell you computers+drives with good firmware?

Re:Death knell

[mcsandberg]

The unix attitude kills another neat technology. When are the unix types going to learn that everything in The Unix Philosophy has been completely rejected by the market place. It took Apple to bring Unix to the desktop and they did it by completely HIDING it - hint hint!

Re:Death knell

[wereHamster]

Even if you have a 100% bugfree drive firmware, silent data corruption is still possible (resilience against silent data corruption is one of ZFS's selling points!). Filesystems that can't handle that simply have no place in todays world. The problem is that one flipped bit can cause ZFS to think that the whole pool is unusable - even though it keeps redundant copies of the metadata which it then completely ignores! What for does it keep the copies then?

Re:Death knell

[Charan]

What good is a fault tolerant file system if it isn't tolerant of faults?

Any time you read about a product that guarantees perfect fault tolerance, there is always a list of constraints that must be met for that claim to hold. You probably won't ever see this list marketed, but it's there somewhere.

I haven't looked into this, but it sounds like ZFS is fault-tolerant given a system model where data can change once it's on-disk, but otherwise system components are fail-stop. So if you ask a hard disk to perform a write barrier and flush its data to disk, the disk will either do so and report success, it will issue an I/O error, or it will catch on fire. Any way, ZFS will handle the situation correctly.

Of course, the immediate next question is whether that failure model is realistic. Turns out it isn't. Some hardware will report 'write barrier complete' when it still has unwritten data in its buffer.

If you can't count on your hard disk to flush its caches or even order writes correctly, I don't think it's possible to build any fault-free file system on top of the drive.

Re:Death knell

[Sancho]

The problem is that one flipped bit can cause ZFS to think that the whole pool is unusable - even though it keeps redundant copies of the metadata which it then completely ignores! What for does it keep the copies then?

Where are you getting this from? It's not in the link you posted.

In the link you posted, the admin found three uberblocks (there are supposed to be four). ZFS correctly made multiple uberblocks, per design. It appears that all three were corrupt. Why? Who the hell knows. Could be that the disk was going bad. Could be the problem I mentioned. Could be a ZFS bug. There's not enough information in that thread to say with certainty.

Now I'd say that ZFS "isn't ready for the desktop" no matter what the reason for the faulty uberblocks. I'm not supporting ZFS by disagreeing with what you're saying--rather, I'm railing against drives that do bad things and developers not being willing to work around them. One of these is the fault of Sun--and it's a major one. The ability to recover from hardware misbehaving is important.

However, the posting you're discussing doesn't have anything to do with "silent corruption"--it's explicitly about an unexpected halt, which causes highly unpredictable results when using drives that misbehave. Hence my bringing up that possibility in the first place. As I said, I don't know how the blocks got corrupted--but neither do you.

Take it from another perspective. If all of the copies of the superblock on an ext3 filesystem were simultaneously corrupted (it doesn't matter how), what would happen? Won't the drive fail to mount, or even fsck? (fsck requires a good superblock, I think.)

Re:Death knell

[Just Some Guy]

We run ZFS on every FreeBSD server and a few desktops. Mostly 64bit. It requires tuning.

Required, past tense, for the most part. Recent releases do the job just fine to the point that I've un-tuned every ZFS system I manage and let the OS handle it. Note: not applicable on 32-bit, but that's a crapshoot anyway.

Re:Death knell

[diegocgteleline.es]

That's what makes ZFS scary IMO. Would you put your data in a filesystem which doesn't have a fsck tool for extreme cases? I certainly wouldn't. What if I hit the same issue you hit? I would lose all my data, there's no fsck. Touching the metadata myself doesn't looks very reliable. I would rather use a filesystem that offers a fsck tool for those extreme cases - fortunately btrfs does have a fsck tool....

Re:Death knell

[diegocgteleline.es]

Which is a shame, since if it did, ZFS would be last file system mankind would have ever needed.

Yeah, Sun's marketing would like you to think that since ZFS filesystem research has become irrelevant. But that's stupid. ZFS is just another filesystem - a good one, but just that. We will see new filesystems.

Re:Death knell

[diegocgteleline.es]

I have been following the zfs-discuss list for years, and almost no one has lost data.

That must be a different list than the one I've been reading....

http://mail.opensolaris.org/pipermail/zfs-discuss/2009-April/027748.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-April/027765.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-January/025601.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027629.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027365.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March/027257.html

Re:Death knell

[wereHamster]

In the link you posted, the admin found three uberblocks (there are supposed to be four). ZFS correctly made multiple uberblocks, per design. It appears that all three were corrupt.

ZFS keeps a history of the last 256 uberblocks in four different places in the pool. So even if all copies of the most recent uberblock got corrupted, it could still fall back to one of the older ones. You'd maybe loose the last few minutes of work, but that's not nearly as catastrophic as loosing the whole pool. It could fall back, but it doesn't, it rather panics the kernel. This is where a userspace fsck would help, for examply by giving you the choice to safely invalidate the last uberblocks. I was not feeling very comfortable when I wrote the dd/ud script that automated that task, but I had nothing to loose at that point.

The silent corruption was just an example. It doesn't matter what causes the corruption. But _if_ you end up in a situation like the admin or me, you have to resort to such ugly tricks to recover your pool. And that is something I'm not willing to accept on a production system - or any system at all for that matter.

Re:Death knell

[Anonymous Coward]

Who'da thought that most of the world has bad hardware?

Sun oversold ZFS. Then when it fails, they blame the hardware. It's never their fault, they're too perfect. That is exactly why they got bought by a software company.

Re:Death knell

[boilednut]

Even if I accept your specious argument that market place acceptance is predicated on the desktop presence, that still doesn't imply that Unix hasn't had a strong impact on the market. Microsoft Windows, especially since Windows NT, has been greatly influenced by Unix -- a point even Bill Gates acknowlegdes.

Re:Death knell

[Score Whore]

Allowing a system admin to invalidate recent uberblocks is one of the tasks currently on Jeff B.'s list. Along with the block rewriter which is going to make a slew of other features possible (pool shrinking, hierarchical storage, etc.)

As far as a single bit flip leading to an unusable pool, I'd like to see a repeatable example. The architecture of ZFS is such that that shouldn't be possible. Even with the implementation bug in the fletcher checksum algorithms, ZFS can detect all single bit errors and through mirroring, parity or ditto blocks, can correct such errors.

I've followed the zfs lists for a while and the only legit complaints that I've come across are issues with zil/slog failures (a failed log device will prevent import of an otherwise valid pool) and the underlying support needed to fix that issue was recently committed to the repository. All the other issues appear to be education problems, like the guy who considered an unmount the same as an export, or defective hardware that doesn't do what it says it does. The file system that can survive active sabotage doesn't exist and never will, and intentional or not, these two cases fall into that kind of category.

Re:Death knell

[MukiMuki]

Okay, there's no need to generalize. Let's look at what really happens in ZFS.

1. Data in ZFS is held in blocks. The verification for those blocks is held in their parent blocks. Meaning, a corrupted block whose corruption manages to return a viable checksum in most filesystems would not do so in ZFS. If it's broken, the parent will tell you, and if the parent is broken, the grandparent will tell you. This works all the way to the highest parent (known as the superblock), which has multiple redundant copies of itself. Basically, it's HARD for shit to break in ZFS.
2. RAID and mirroring can tell you if a disk is bad, and if you're rebuilding, if a sector is bad. But the latter doesn't work unless you're scrubbing. ZFS catches errors like that while reading, and then it fixes them while it's sending you the good data.
3. Let's say you have 8 1TB drives in a RAID6 configuration. Let's say you have about two terabytes of data across the whole thing. Let's say a drive fails. You replace it. The entire drive now has to be rebuilt. ZFS only needs to fill the 160 megabytes that drive actually contains.
4. Data in ZFS is held as a tree. This can make some things slower (possibly why ZFS tends to aggressively cache) but it also means that stuff like snapshotting is built into the filesystem and cheap as hell to do. You want to snapshot your OS's root folder before a risky patch? Go ahead! If anything breaks, you can roll back instantly.
4.a. Feel free to correct me on this, as I've never tested it, but as far as I've read, ZFS is probably the only filesystem that could survive an rm -rf / and a (single) accidental dd at the same time, the latter under a RAID-Z2 config.
5. Cloning is just as easy as snapshotting. Lets say you have a developer account or VPN account template? The files that you start out with only need to be held once on your hard drive. Only edits to those files result in new data being stored.

Basically, ZFS works best with the fact that both hard drives and RAM are getting cheaper. You could put together a system with 8 gigs of RAM (more if the motherboard supports it) and 8 terabyte drives (plus a spare) for under a grand. That's 6 terabytes of lightning fast (about 120 megs a second I'd imagine), absurdly reliable (it's statistically nearly impossible for the same block to be broken across two drives, and unlike RAID, ZFS won't stop rebuilding if that happens. It'll just report which files were affected)

It's essentially a filesystem designed for 2009 (or whatever year this happens to be for at least the next 10), and people who need a ridiculously good filesystem on a budget.

Did I forget to mention that adding space is only limited by your hardware? (e.g. available sata slots, or available PCI slots for new sata cards) Or that if a drive gets disconnected (say, you have them all on a USB connection) and you reconnect it, ZFS only adds the missing data since it was disconnected rather than rebuilding the whole drive? (What RAID does, mostly because it doesn't know anything about the underlying filesystem)

Re:Death knell

[Score Whore]

For the rest of your post, I am simply too lazy to prove you wrong. For a beer each I could fiddle out those that were confirmed to lead to data loss, including unrecoverable data loss, as I mentioned in my post.

This is what the world commonly calls fud. And the appropriate response is put up or shut up.

Those exist in four-fold. Why? It seems the consistency of blocks on the drive being guaranteed, the layer of actually having the links to those correct data is more vulnerable. Think of a pool: if you jank the structure of a pool by janking a USB, you have 100% correct data (contrary to any other file system, I agree), but alas no more structured access to reassemble them (compared to inodes).

I have no idea what filesystem you are talking about, but it's not ZFS. Every time a txg is committed, the entire on disk structure is completely valid. The "USB problem" (also shared by some of the SIL controllers) is that the device reports the I/O as complete when it's not, then when the device finally gets around to actually writing the blocks to nonvolatile storage, it can be done out of order. At which point you're fubared neither your metadata or data can be said to be correct, and the same problem exists for all filesystems. The only reason UFS descended and inspired filesystems can be partially recovered is because they have a fixed on disk structure, which ZFS, JFS, VXFS don't have. (On the other hand ZFS, JFS, VXFS won't ever run out of inodes on you.)

Not being able to use crappy hardware, but getting full checksums, snapshots, ssd backed intent logs and l2arc -- that's a trade off I'm gleeful to accept.

Re:Death knell

[afidel]

Oh god the Ultra II 450 cache bug, that one was annoying as hell.

Re:Death knell

[georgewilliamherbert]

Kono, that's not exactly true. I've also been on the zfs-discuss list for years, and there are at least two unfixed issues in it that I have seen.

First was the unplug-a-disk-keep-writing problem, where data kept being written into the cache but not committed to disk, so you got a consistent return and write verification at the application/OS level but on reboot the data's gone. This was first identified some years ago by Darren Dunham and posted to zfs-discuss by him and myself, using a E250 and the earliest public Solaris 10 betas. Nobody ever answered the question until very recently where someone else spotted the mechanism behind it (writes going to cache and being acknowledged, but not committed to disk). Still not fixed that I know of.

Second is a low level zpool / iscsi issue, where under some circumstances you can get into a situation where writes go into the cache and are acknowledged but reads get an older, "stuck in time" version of the data (we encountered this trying to manually overwrite an iscsi mounted Oracle RAC shared disk which was having Oracle problems, trying to dd zeros on top of the device... could dd all we wanted, either locally or remotely, but reading the disk kept stuck at the old Oracle ASM header). Nobody's exactly sure what's up with that one.

That said - UFS, VXFS, NFS, every filesystem in the world has had some bugs. Anyone who thinks otherwise is silly. Sysadmins and system architects have to plan for this...

Re:Death knell

[georgewilliamherbert]

That's not good enough for the likes like me.

I suppose all the UFS, NFS, VxFS, EXT2, EXT3, Reiser, et al filesystem bugs were not good enough for you either?

Anyone who thinks any filesystems are by nature entirely perfect is naive or too new to be pronouncing wisdom. They're pretty thoroughly debugged, but that's different than being perfect. The hardware/software interactions change over time, breaking design assumptions even in older FS code that's probably completely debugged. You get subtle hardware or firmware flaws in chips somewhere in the data transfer chain.

Things go wrong.

Either you understand this and prepare for it, or you're in trouble.

ZFS handles a lot of failures that other filesystems don't even realize happened, or can't recover from. It also has some new and somewhat bizarre failure modes of its own. You win some, you lose some.

Re:Death knell

[carton]

Almost no RAID systems can do what ZFS does. Hints: end to end checksumming; self-healing; copy on write; ...

No. This is missing from RAID-on-a-card and software raid like LVM2, but, NetApp Hitachi and EMC all have checksums and all do self-healing. See

(1)
(2)
(3).

ZFS pundits make a big deal about the ``end-to-end"" nature of their checksums, but the storage vendors design aroudn actual observed failures while the ZFS pundits tend to tell anecdotal war stories or defend against hypothetical problems. It's good that ZFS has protection from the failures their competitors have discovered, but the aggressive punditry is dishonest FUD.

NetApp does COW and has similar high-performing snapshots/clones at the cost of needing a defragmenter for databases to stay fast. However NetApp has said defragmenter and ZFS doesn't.

Re:Death knell

[otopico]

You sir FAIL.

This is /. Making that much sense in one post is forbidden.

Who would think that not any one thing is perfect, but, in some cases, one thing is better than another? Madness.

OSX abandoning ZFS surely has its reasons, but it would be nice to see OSX developed in a way where the user decided which fs suited their use best and let the user decide the pro v con on one over the other.

Imagine a world where the tool was chosen by its function, not the fandom of one thing over another.

Re:Death knell

[ToasterMonkey]

NetApp is the reason we have ZFS. I thought this was pretty obvious, and I'm not real big on reading blogs.
Nobody here (that I've read yet) is comparing the two, and it is not surprising they have similar functionalities, given the above. One is a NAS, one is not.
This discussion is centered on filesystems (hopefully you understood at least the headline of the fraking page), and RAID was brought up in comparison to software RAID features of some filesystems. WTF direction are you coming from?

ZFS pundits make a big deal about the ``end-to-end"" nature of their checksums, but the storage vendors design aroudn actual observed failures while the ZFS pundits tend to tell anecdotal war stories or defend against hypothetical problems. It's good that ZFS has protection from the failures their competitors have discovered, but the aggressive punditry is dishonest FUD.

Nice strawman, but who are the competitors you're speaking of, and where is the "FUD" directed?? Other filesystems, or NAS/SAN systems? Do you want to show me how to format a local disk with WAFL on a Solaris, OS X, Windows, or Linux host? How is it even in the same arena as local filesystems?

Are you trying to make the argument that SAN & NAS competes with local storage, or that existing filesystems are 'good enough' - as long as they are backed with expensive (see Hitachi/EMC) backends? I cannot understand what corner you think you're in that would make you get all hostile towards ZFS. Is it the "not ZFS" corner? Are you just against advanced filesystem development in general? I hope not, because you can be sure as shit, they will continue to absorb SAN/NAS features.

Local storage is not going away soon (maybe never), and having some of the features of high end SAN and NAS systems for free is a Good Thing(TM).
Also, having most of the features of a high end NAS system overlaid on your SAN system is pretty fucking useful too. How bout dem apples, NAS weanie?

Re:Death knell

[ToasterMonkey]

In the link you posted, the admin found three uberblocks (there are supposed to be four). ZFS correctly made multiple uberblocks, per design. It appears that all three were corrupt. Why? Who the hell knows. Could be that the disk was going bad.

I thought this was hilarious, from GP's link:

"I have a ZFS pool that has been corrupted. The pool contains a single device which was actually a file on UFS. The machine was accidentally halted and now the pool is corrupt."

Re:Death knell

[ToasterMonkey]

Well here's the thing. Almost all Macs rely on FireWire and USB for storage beyond the builtin disk.

Good point, but why would Apple ship cheap FireWire/USB controllers that lie to their own software, breaking it?
This issue really underscores the importance of Apple's hardware & software integration.

Re:Death knell

[ToasterMonkey]

GP said market rejected UNIX, you say it strongly influenced market anyway, and Windows NT in particular.

I think that's pretty funny considering Windows NT is THE evidence of the market's rejection of UNIX. Nobody can argue that NT didn't trounce UNIX, highlighting (again) how important usability is, even in datacenters. Linux demonstrates that 'usable' UNIX's are in demand though.

Re:Death knell

[hotfireball]

like unusable system, if you pull the power, and pull the power again while it is restarting; Like slowness under specific conditions; like rendering the file system unbootable, reproducibly, when using a specific setup of snapshots.

What-what? Especially what means your statement about "specific setup of snapshots"?.. Unstable system if you pull the power? Go install VirtualBox, run some heavy-writing process on open solaris and start enjoy tearing it down by powering off virtual machine (i.e. kill -9). If you can to destroy it this way, of course. Also do the *same* on ext3 or especially XFS and see which FS will go nuts first. I bet ZFS will work rock stable, while two others will need fsck or even restore from backup (XFS especially).

I am not saying ZFS is completely saint, but just I have an allergy to some portion for BS, so excuse me.

Re:Death knell

[boilednut]

Windows NT is THE evidence of the market's rejection of UNIX. Nobody can argue that NT didn't trounce UNIX

Windows NT's "trouncing" of UNIX is more an indication of Microsoft's market MANIPULATION: Microsoft used various means, many of which nefarious, to leverage its monopoly to shoehorn its way into the server market. Hardware costs were also a factor: NT ran on relatively cheap x86 processors -- while Unix, at the time, did not. I don't dispute that NT was a passable server OS; in fact, to get back to my point in the GP, many of its best attributes where derived from Unix -- as Bill Gates acknowledged:

Well, Microsoft stepped back and looked at that situation and said that the best thing for us might be to start from scratch: build a new system, focus on having a lot of the great things about Unix, a lot of the great things about Windows, and also being a file-sharing server that would have the same kind of performance that, up until that point, had been unique to Novell's Netware.

And through Windows NT, you can see it throughout the design. In a weak sense, it is a form of Unix. There are so many of the design decisions that have been influenced by that environment.

Regarding Linux, rather than improved usability, cost was the primary factor why it gained market share from Unix: other than support, Linux is free; and, as with Windows, Linux runs on x86. Actually, in terms of usability, features, and robustness, Solaris rivals, if not surpasses, any Linux distribution.

Re:Death knell

[ishobo]

Required, past tense, for the most part.

If it is for the most part, it is not past tense. Also, not everybody runs CURRENT or STABLE.

Re:Death knell

[udippel]

Especially what means your statement about "specific setup of snapshots"?

I mean, since you ask you should be answered:
We had set up a system with snapshots and rollback. If I am not mistaken, nv95.
Just to try, we used ZFS volumes and ZFS partitions.
So far so good. Only, at rolling back a snapshot of ZFS volumes, the system crashed and could not be rebooted, no way, no failsafe, no nothing, no data to be recovered. ZFS partitions could be rolled back without problem, however.
So, another go, nv110. Same thing, same result. All data gone forever, even failsafe boot-cycling.

That actually was the moment when we decided to call it a shot and never touch ZFS again. Confirmed, we have no rollback of snapshots now; but at least our systems don't self-destroy completely.

Re:Death knell

[hotfireball]

Thanks.

Is it like you want to do rollbacks/snapshots on volumes? This exactly works for me with no problems at all. Maybe next time just watch your hardware and do scrub more often or something?.. :-)

Re:Death knell

[Just Some Guy]

"For the most part" being in that 7.2-RELEASE, on amd64, no tuning at all is necessary unless you have specific workloads (like database access). That's also true of UFS, where you'd want to tweak block size and inode density and such.

Re:Death knell

[aurum42]

Sounds like an interesting story--what was the Ultra II 450 cache bug? Cursory google("ultra II 450 cache/errata") didn't come up with anything.

Re:Death knell

[afidel]

Here's an article talking about the software "patch" that Sun came up with before finally admitting they had bad parts. The company I supported at the time ended up having thousands of the processors replaced with parts with redundant SRAM modules from whatever their best supplier was. They were literally getting multiple system halts a day across their enterprise caused by the bad cache SRAM. Sun tried blaming it on cosmic rays and some other junk before finally issuing a replacement order under their enterprise support agreement.

Re:Death knell

[ishobo]

Hence, why it requires tuning and is not past tense. Please go reread what I said and what you wrote. The ZFS code in 7.2R does not mitigate tuning in general, only in limited use siutations and with 4GB or more of memory.

7.2R was released last month. Anybody that puts into production, software that has been released less than thirty days, should be flipping burgers. I do not work in Internet time and if any of my employees tried a stunt like that, it would be instant termination.

We recently, as in yesterday, started rolling out 7.1R. That codebase spent three months in QA, with another three months in staging, before it was deemed ready for production. It took me three months to plan and test a Perforce upgrade.

Re:Death knell

[carton]

NetApp is the reason we have ZFS. I thought this was pretty obvious

Obvious? yet I'm the first person to mention it. Anyway there is not a problem with stating something that's obvious, as you seem to imply there is.

Are you trying to make the argument that SAN & NAS competes with local storage,

You just said that yourself, sorta. You said NetApp is the reason we have ZFS. Yeah, yeah, go ahead and redirect and tell me precisely what you mean which you will now flesh out to have nothing to do with ZFS in the NAS/SAN space.

But you'd be wrong if you did that. Yes, ZFS is absolutely designed to steal customers from the high-end NAS market. And if you read the OpenSolaris ZFS list, it's absolutely clear they are competitors. It's also a good fit for some SAN cases which is why it has zvol's---there are two iSCSI targets in OpenSolaris, iscsitadm and COMSTAR. The latter can emulate FC targets as well. Finally, Sun sells a NAS box, the 7000. It's based on ZFS plus some extra closed-source bits to make the web interface, and I would guess it's a different (newer) branch of Solaris as well since many ZFS bugs are fixed in the unstable nevada/opensolaris releases that are not fixed in Solaris 10.

They are also selling disk shelves based on SAS expanders designed to connect ~50 - 100 spindles to one CPU---basically they have a disk chassis with a pull-out CPU card, and if you use the CPU card you get an x4540 disk-heavy node, while if you use the SAS expander card you get dumb CPU-less storage with a few SAS interfaces that you can attach to a plain node. so on the hardware end, also, they are trying to increase disk density through using shelves and semi-proprietary head-to-shelf interconnects the same way as NAS/SAN market.

personally I think IB is a more interesting encroachment on the NAS/SAN space and wonder why it has not arrived yet. But Sun has invented some threats that are interestingly cheap to manufacture for what they do (unfortunately, not correspondingly cheap to buy!).

On Apple it would compete with XRaid if they would sell some dumb shelves. Even without dumb shelves people would make zpool's on their XRAID LUN's. Does XRAID do checksums? I don't know.

I cannot understand what corner you think you're in that would make you get all hostile towards ZFS.

I cannot understand why people can't read an extremely short fact-based post without having these blinding emotional ad-hominem reactions and trying to determine my corner so desperately they cannot hear the simple things I am saying.

The corner I'm in was: hearing someone say ZFS is revolutionary because it checksums data. which is bullshit since all the high-end vendors have been doing this for like a decade. ZFS tries to distinguish itself from other checksummers with the ``end-to-end'' language I mentioned, but I think the distinction's irrelevant. I think the more relevant distinction is that NAS/SAN vendors do *a lot* more testing. But ZFS does still encroach on their territory. You're wrong to think of it in a little ``local storage'' box.

How bout dem apples, NAS weanie?

I hate netapp. They are expensive and impossible to deal with. They squash the used market with contracts of adhesion that I think should be illegal. Their software is utterly proprietary. Their user community is these ``i don't care about politics I just want to get work done'' wankers who don't mind discussing their problems with a vendors' products on closed NOW forums censored by the vendor which you have to pay to access. It's a stifling, expensive, arrogant environment like Meraki, Allegro, Wolfram. In spite of the extremely high quality you are better off if you can stay well away from this kind of company. And although NetApp fucking works and ZFS is, kinda flakey, none of these problems apply to ZFS. however, all of that's a separate discussion than the one we were having about which ideas are new, revolutionary, or irreplaceable in ZFS.

Of course if you insist on reading every post with an implied thesis of "* sucks" or "* rules" then nothing is separate. You should stop doing that.

Re:Death knell

[aurum42]

Interesting, thanks. It sounds like the cache controller/circuitry surrounding the cache itself emitted "particles", from that post. But then it goes on to talk about humidity etc. Plus, they mention about a 1% CPU time effect, but if you flush the cache you could be affecting other processes' performance too and it's not clear if that's taken into account. Weird. Did they replace it with "mirrored SRAM" which they say is the only real fix ("not available on midrange systems"), or just another box with tuned up scrubbing parameters and what not?

Re:Death knell

[carton]

UltraSPARC II is one of the oldest UltraSPARC chips.

They had really good ECC on the DRAM---not only did ~all? of the SPARC machines even low end have ECC DRAM, but also when a stick went bad, 'dmesg' would tell you exactly which one to replace. Unlike PeeCees they really finish the job.

But prior to UltraSPARC III Cu, they didn't have ECC for the L2 cache. And the L2 cache on these chips was extremely large for their era, like 2MB on a 400MHz chip.

Part of what the poster might be referring to, is that the failure's nondeterministic. Once Sun support traces down one failure to L2 cache bit flips, every time something with a machine happens that they can't explain they'll say ``it's the L2 cache ECC problem, shrug, goodluck.''

It's probably a common practice with any engineers, which starts with the customer demand, ``no, you must work on my problem until you can explain the failure,'' which seems completely reasonable especially when you are paying them a fat yearly fee to do exactly this. Then you find yourself on the other side, and it's just impossible. It would be better if they were scientifically honest, but they're in a business position where this is impossible.

The big problem is when other parts of the culture start to internalize this scapegoating behavior. That's what's happening with ZFS now, where people like Richard Elling blame this corrupt ueberblock problem on bit-flip gremlins. The argument goes, ZFS gives you an error message like ``corruption detected'', and they read the error message and say ``oh the self healing couldn't work because you didn't have redundancy at the zpool layer. See, it says right there, corruption.'' They're using ZFS's error message to exhonerate ZFS, along with a bunch of anecdotal hypotheticals on which they don't follow up.

The problem tends to happen when you reboot an iSCSI target without rebooting the host. It's ok to reboot an iSCSI target, so long as you also cord-yank the host while the target is missing. If you don't, you can imagine a stream of writes headed toward the drive with a few writes in the middle just knocked right out. I think there's a problem with the error recovery state machine in the iSCSI initiator or ZFS or somewhere else in the storage stack. The NFS client-server connection can recover perfectly if the server reboots and the client doesn't, but I'm not sure iSCSI is up to the same level. You can imagine the same type of problem happening with a USB/Firewire drive that goes away while mounted _and then comes back_---something in the USB layer might auto-retry a few times thinking the USB connection is noisy, finally get through, and courteously hide this failure from the upper layers, but meanwhile unbeknownst to this hand-waving recovery state machine the USB drive has lost power, and (validly!) lost all the data in its write cache. The drive is allowed to do this, if it hasn't received and completed a SYNC CACHE command, but the upper layers of every filesystem we've got probably assumes lost-the-drive-write-cache event will happen only when the *host* also loses power so ideas like, ``you need to double-cache writes in the scsi disk driver and replay them if the drive goes away and comes back'' or ``you need to force-unmount filesystems on the slightest blip of complaint from USB/iSCSIinitiator layers'' are missing from most filesystems and storage stacks---so it is actually hurting other filesystems, too, but less disastrously. Unfortunately this is all unproven speculation from me, no better than the bitflip gremlins some ZFS fanboys are proposing.

The checksums on NetApp are not actually a single checksum but several at different layers in the storage stack. They adapted their checksums to the problems they were actually observing. Consequently, when a checksum seal is broken, it's helpful in tracking down where the problem happened. ZFS checksums, OTOH, often get broken when there's no silent corruption at all---for example, when half a mirror is out of sync. They're still doi

Re:Death knell

[Just Some Guy]

The ZFS code in 7.2R does not mitigate tuning in general, only in limited use siutations and with 4GB or more of memory.

Yes it does - in general. There are edge cases where you'd need to tune any filesystem because you, the sysadmin, know more about what it needs than the OS can guess. As of the current release, no tuning at all is needed for routine use.

7.2R was released last month. Anybody that puts into production, software that has been released less than thirty days, should be flipping burgers.

I think I see the disconnect: you hadn't previously mentioned that you were insane. Well, best of luck with that!

BTW, I've been running -STABLE in production for over a decade. With the exception of FreeBSD 5 before 5.2.1-R, I've never seen a release that wasn't an improvement over the previous release. I've also never found -RELEASE to be "better" than -STABLE, given that -STABLE gets more bugfixes and it gets them sooner. Basically, I can see why you'd want to run -RELEASE (even if I personally don't), but I definitely can't see why you'd want to run old versions of -RELEASE on general principles alone.

Re:Death knell

[afidel]

They replaced them with mirrored SRAM CPU's. The real issue was one of poor design, they had ECC throughout the system including system busses but had only simple parity checks on the SRAM. By having essentially RAID1 on the SRAM they could recover from most flipped bit problems, the exception being writeback cache errors that had already pushed bad data to main ram (silent data corruption). Those were much less common than data cache problems that caused system halts and could have their impact mitigated by turning up the cache scrubbing interval.

Re:Death knell

[ishobo]

Clearly, you have never worked for an organization that stresses quality.

no tuning at all is needed for routine use.

That statement is meaningless, there is no such thing as routine use. My needs may be routine to my organization but not others.

Well, you certainly reinforced the statement in my signature.

Re:Death knell

[Just Some Guy]

Clearly, you have never worked for an organization that stresses quality.

You have clearly demolished me with your sagelike wisdom and rapier wit. Good day, Sir.

Re:Death knell

[aurum42]

Interesting--I'm sleepy enough that I can't do justice to your post, but do you know how many of these hypothetical ZFS improvements/better approaches cannot be done in a straightforward manner because of say NetApp patents? (NetApp sued Sun, as I recall).

Re:Death knell

[speedtux]

You should not talk so authoritatively when you are so obviously ignorant of the subject.

Funny, neither should you.

Like you point out, there is lot of bad hardware out there. What you overlook is that existing filesystems have no facilities to catch, much less correct such errors or corruption; that is why it is called silent data corruption.

I don't "overlook" that at all; since that's what real-world hardware is like, real-world fault tolerant software needs to deal with it.

Those improvements will only allow the possibility to recover to a consistent state, but data will still be lost.

Data that doesn't ever get written will obviously be lost. However, it appears that ZFS problems with such hardware go beyond that.

Re:Death knell

[KonoWatakushi]

I don't "overlook" that at all; since that's what real-world hardware is like, real-world fault tolerant software needs to deal with it.

Not at all. No one outside of ignorant home users tolerate such hardware. In the real world, hardware that ignores cache flushes (ie. does not guarantee the ordering of writes) is absolutely not tolerated. This is not a fault, and it can't be worked around in software.

Data that doesn't ever get written will obviously be lost. However, it appears that ZFS problems with such hardware go beyond that.

Again, you are missing the point, this has nothing to do with unwritten data. Bad hardware as described above can still damage traditional filesystems beyond repair, though usually the corruption is more localized. It's not that it doesn't happen, just that you usually won't find out immediately unless it's catastrophic. By the time you discover it, the errors may have already propagated to your backups as well, and then you are screwed.

I should have known better than to post in an Apple focused thread. It is no use trying to inform the willfully ignorant.

Re:Death knell

[badkarmadayaccount]

I make USB based SANs, you insensitive clod!

Perhaps it will BE ZFS just not BE CALLED ZFS

[KenCrandall]

WIth the impending purchase of Sun by Oracle, I'm thinking it could be one of 2 things:

1) ZFS will be killed and/or de-emphasized and/or re-licensed in such a way that Apple is not comfortable/happy with putting it into Mac OS

2) It will still be ZFS just not called ZFS anymore (either re-branded or forked by Apple or re-named by Oracle/Sun)

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Bill, Shooter of Bul]

1) Oracle hasn't publicly said anything of that nature, nor is even any rumors to that effect.
2) They aren't mentioning the features that zfs provides under any kind of name

Most likely, they've been focusing too much on the embedded space with the iphone and didn't have the man power to integrate a complex third party FS into their OS. As it was only going to be for the OSX Server for "production servers", they probably thought that was the easiest thing to drop. I mean, lets be honest no one really uses OSX Server for anything really mission critical that relies on it for the kind of storage capabilities ZFS would provide. Do they? Feel free to correct me with real world usage senarios of OSX Server ( I haven't heard of much).

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[BrokenHalo]

either re-branded or forked by Apple

Well, I hope they work something out. I've been looking for a good cross-platform filesystem to work between my Mac and Linux boxes; at the moment I'm using HFS+ but am not entirely happy with the way it u/mounts on Linux after having been written by OS X. I've seen suggestions to use NTFS, but that doesn't do proper *nix permissions.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[beelsebob]

I'm fairly confident of what it is, having actually used zfs on OS X.

1. The implementation still has some major bugs -- I managed to get a kernel panic with it just by writing to a raid-z.
2. There are some unresolved issues just with the way zfs behaves, for example, pulling a USB device with a zfs volume on it *must* cause zfs to shit its pants, because it's guarenteeing that writes to it will work.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[MichaelSmith]

At my workplace we migrated to a brand new sun NFS server with ZFS and hit a critical bug in the first two weeks. If Sun can't get it right I don't expect others to.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[TheLink]

Can you reveal what sort of critical bug it was?

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[isorox]

I mean, lets be honest no one really uses OSX Server for anything really mission critical that relies on it for the kind of storage capabilities ZFS would provide. Do they? Feel free to correct me with real world usage senarios of OSX Server ( I haven't heard of much).

I guess XSans may use it. I don't know much about them to be honest, another department at work has a small one for FCP editing. Seems to me that it's the same as any old san.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[MichaelSmith]

Its an nis + automount + zfs + nfs problem. I am a user of the system (not an administrator) so my information is incomplete. Basically we lost the ability to export deep subdirectories (say /path/to/user) from our zfs file system (which is physically on a raid array) via nfs.

We retained the ability to export /path/to as a workaround. The way nis (yp) works in our setup is that it exports individual user directories as required.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Divebus]

o one really uses OSX Server for anything really mission critical that relies on it for the kind of storage capabilities ZFS would provide. Do they?

Just the iTunes store. Millions of people beat on it every day. However, the insane demands of simultaneously activating a gazillion new iPhones has brought the iTunes servers down with essentially a DDoS attack.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Anonymous Coward]

Mac OS X Server has a few features that are hard to replicate well on other servers, basically coming down to specific Mac management (Open Directory, NetBoot, Software Update), and in particular AFP file services. There are a lot of design/production companies out there with a lot of Macs who need a reasonable amount of storage, and AFP still tends to work better for Mac clients than things like SMB. We've got a few clients with a few hundred Macs and and ZFS would have been a good additional option to have for backend storage. The snapshot and scrub features alone would be a big benefit.

Xsan is great for certain situations but Apple's tools tend to target that towards video production, and not everyone needs or can afford a full SAN.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Anonymous Coward]

Well, that and ZFS doesn't provide a whole lot of new, unique capabilities. Don't get me wrong -- ZFS is not a bad idea -- but 96% of what people are excited about can already be done in BSD/linux, and to a lesser degree even with Windows and OS X, with existing technologies like LVM, softraid, and the creative use of mount points. So if you have a real need for the sorts of things ZFS does it's probably not that interesting because you're already doing something similar and there's a high cost and risk involved in switching.

In general though I think you're right about OS X Server -- it gets used in the same sorts of cases where Windows Server does, and for the same sorts of reasons, but it's probably not what you'd pick outside of those scenarios. OS X Server is probably not the right choice if your requirements are just "we want a mail/whatever server" but it makes sense with arguments like "we're supporting desktops with the same family OS" or "this program requires to run", and to a lesser degree "we're mostly a shop, so it's easier to keep everything the same".

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[jipn4]

Why would Oracle want to make it hard to use ZFS? ZFS has an uphill battle to gain acceptance anyway.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[prockcore]

The iTunes store uses Akamai. So it uses Linux, not OSX at all.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[ILongForDarkness]

Well you can just use UFS :-) An oldie but still works. ZFS would be nice but it is a little bit obscure for mainstream use. I can just imagine a whole bunch of Mac users or Linux users deciding to use the other platform and wondering how to share a filesystem. "Dude make that array ZFS", "What's ZFS?". FAT32, NTFS and UFS are pretty much universally supported because of the fact that they are historically the dominant filesystems. Going out of your way to get a new filesystem compatible with everything else is less likely than sharing things on a service level (a la, samba, NFS). One chooses the filesystem that everything uses (with the requirement of rebuilding on the new filesystem if you didn't choose the right one back in the day), the other just requires installing and setting up a program on the system. Philosophically I prefer to chose the filesystem, RAID level, stripe size etc, based on the data that is going to be stored without worrying too much about how to get the data on and off disk from a remote client. For personal use I think FAT32/NTFS is going to be the standard for a long time. You might not like Windows, you might not use Windows, but chances are somebody is going to want to borrow your external drive/get data off of it that is a Windows user and the easiest way to make that happen is if the drive is something that windows can understand. Lowest common denominator.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[MShook]

Don't sweat too much, at work we're still hitting some serious UFS bugs on patched Solaris 10 (mainly FS corruptions, huge slowdowns like a fstat taking 20 real minutes, ...). That said we're a little bit shy of 2000 Sun SPARC servers so that's why we "often" see these bugs...

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[CarpetShark]

There are some unresolved issues just with the way zfs behaves

This is a lot like XFS on Linux. There were some very nice qualities to XFS, but at the end of the day, it wasn't designed for desktops, and would happily hose the entire partition if the underlying hardware didn't have enterprise-grade reliability.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[LKM]

Apple uses Akamai for mirroring some of their stuff. They use Xserves as the main source.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[BrokenHalo]

...but chances are somebody is going to want to borrow your external drive/get data off of it that is a Windows user

That is one circumstance I do not want to see. If any Windows users are trying to get data off my drives, I'm being hacked.

But getting back to your earlier point, UFS is more problematic than HFS+, because it only has read-only support on Linux. FAT32/NTFS are useless because they trash any Unix permissions.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[totally bogus dude]

I wouldn't think Akamai would be doing any of the actual work behind the iTunes store. I seem to recall they do have that capability, but it would be really hard to take advantage of unless you designed for it from the start, and even then I doubt anyone, especially a company as large as Apple, would be happy to give their content distribution network access to any of their actual user data.

Our website is served by Akamai as well, but nearly all the content is served by Windows web servers. If you do a simple GET and the page is in the cache of the Akamai server you're using, then you could maybe say it was served by Linux or whatever. If you do a search or anything that requires actual work, your request will be getting funneled back to our Windows servers.

I would say it's extremely unlikely iTunes works any differently.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[beelsebob]

Sure they have http://zfs.macosforge.org/trac/wiki#ZFSDocumentation you just don't know where to get apple's current head of their zfs implementation.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Anonymous Coward]

ntfs-tools package
ntfsfix /dev/sdXY :) no need for chkdsk

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[ILongForDarkness]

It might be buggy still, I'm not sure, but according to http://www.linuxforums.org/forum/ubuntu-help/115396-edit-kernel-support-ufs-read-write.html among others you can install/enable a kernel mod to support ufs in read/write mode.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[kriston]

No, sorry, iTunes is not mirrored. It really is all on Akamai.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[DrgnDancer]

At least one major Linux vendor does not support r/w ufs in its kernel. We installed a new RHEL box to replace an aging Solaris file server and were a bit shocked when we discovered it couldn't mount the ufs SAN filesystem that we'd beeen serving. Luckily we had enough space available on the SAN to cut out a new file system, build it ext3, and copy the data from the ufs read only mount.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

They don't, Xsan uses the StorNext File System. Apple licensed it from Quantum. In fact if you buy StorNext FX or FX2 you can talk to the SAN as if it were a block device as they provide drivers/kernel extensions and tools for lots of versions of Windows (32 and 64 bit), Solaris (sparc and x86), Linux (a few 32 and 64 bit distros), AIX, HPUX, and even IRIX (basically only the BSDs, which actually matters, and the dinosaurs VMS and Ultrix are out in the cold):

http://www.quantum.com/Products/Software/StorNextFX/Index.aspx
http://salestools.quantum.com/getDocPRetriever.cfm?ext=.pdf&type_mime=application/pdf&filename=294835.pdf (warning pdf)

When you buy Xsan from Apple you get block level kexts and tools for OS X of course.

ZFS SAN really only has been rolled out for Solaris clients. Everything else would have to treat it as NAS via cifs or nfs.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

I'm am so glad that the entire world has not forgotten about how to use NIS to mount homedirs for all workstations. Seeing LDAP take over has been heartbreaking, since so many places just end-up using Windows as the server. I'm sorry to hear that it stopped working right with NIS and ZFS. Did you have this sort of structure:

Very many entries like this for all of the user names:

tank/home/username /export/home/username

And it was worked around by simply doing this:

tank/home /export/home

I can see how if you only had one /export/home type line in the dfs/sharetab but used a tank/home/username type of filesystem for each user that would not have worked. Your admin might get it to work by simply adding a line for each file system that was created for each user in the sharetab, ie one for each mounted under /export/home/username, you can see how things are being exported by typing share on the Solaris NFS server, there should be an /export/home/username for every filesystem mounted under /export/home. I am assuming that is the way the admin set-up zfs home dirs since then he can get quotas for the home dirs and user, as well as restrict the nfs sharing to only certain users and even from certain IPs.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[MattBD]

Only one I've heard of outside Apple is Ma.gnolia, which isn't a great endorsement since they went down and lost all their data...

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

I know you said UFS but you don't use any software from Veritas do you? I've seen Veritas kernel modules dick with vfs and cause trouble.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[MattBD]

I was thinking probably relicensed under the GPL - I guess this would make sense for Oracle to do this as it would mean it could be integrated into the Linux kernel, and if they were to relicense the whole of OpenSolaris under the GPL it wouldn't cause any problems. However, I guess it could mean Apple might not want to use it anymore - my (very!) shaky understanding is that you can't link GPL'd code to code under an incompatible license at compile time, and isn't the license Apple use for their OS kernel incompatible with the GPL? That would mean they could no longer incorporate ZFS into the kernel unless they were to fork it. It could still be implemented in user space, I guess, but that would slow it down, and it would still be impractical to use as the main OS. And of course there's the issue of Btrfs - will Oracle relicense ZFS so it's Linux compatible when they're already working on a rival? I guess we'll know sometime soon.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[saleenS281]

What are you talking about? The COMSTAR project will present LUNs out to host devices via FCP or iSCSI. It doesn't matter what OS the host computer is running.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

I answered the question that Xsan does not use ZFS, rather StorNext FS, technology Apple paid Quantum for. The SAN in this case is an Apple computer (likely an Xserve) connected to a storage array via fiber. Then Xsan provides software that other Apple clients can use to use the SAN. You can buy some software from Quantum if you want use the SAN as a block device from Windows, Linux, Solaris, etc clients since the FS and protocol are identical.

Solaris has got it's own ways to act as a SAN but it is not Xsan.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[saleenS281]

You said:
"ZFS SAN really only has been rolled out for Solaris clients. Everything else would have to treat it as NAS via cifs or nfs."

So again, what are you talking about? Solaris has a fully functioning "SAN" target. It doesn't have to serve via cifs or nfs.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

What I know is that you can create a zfs pool and then an empty fs in it on a solaris box. Then you can do FCP or iSCSI to it. But if you have a WIndows initiator say using iSCSI you would format it as NTFS in order to use it. Likewise for Linux you would make an ext2 fs. If you have a solaris initiator you can just create a zfs fs in your pool with default options and then it is just like a zfs fs in a pool over iSCSI instead of SCSI for the client. That is what I meant by that comment. So you either create a three vols, one NTFS, one ext2, and one zfs and use a block device from your clients, wasting capacity and losing the easy reconfiguration on NTFS and ext2 (you could be really crafty about LUNs and get a volume manager running for Linux but you need to learn all that complicated stuff that zfs made so easy), or you make some zfs volumes in your pool and not lose all that. But for your Windows and Linux initiators you would need to share those fs via cifs and optionally also nfs from the solaris SAN.

Is there some new development I am not aware of?

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[saleenS281]

What I know is that you can create a zfs pool and then an empty fs in it on a solaris box. Then you can do FCP or iSCSI to it. But if you have a WIndows initiator say using iSCSI you would format it as NTFS in order to use it. Likewise for Linux you would make an ext2 fs. If you have a solaris initiator you can just create a zfs fs in your pool with default options and then it is just like a zfs fs in a pool over iSCSI instead of SCSI for the client. That is what I meant by that comment.

That's not at all true. You can't remote mount a ZFS pool. If you present out a block device from a Solaris box, the remote box treats it like a standard SCSI device, regardless of what the remote OS is.

So you either create a three vols, one NTFS, one ext2, and one zfs and use a block device from your clients, wasting capacity and losing the easy reconfiguration on NTFS and ext2 (you could be really crafty about LUNs and get a volume manager running for Linux but you need to learn all that complicated stuff that zfs made so easy), or you make some zfs volumes in your pool and not lose all that. But for your Windows and Linux initiators you would need to share those fs via cifs and optionally also nfs from the solaris SAN.

Is there some new development I am not aware of?

No, it's just that what you're currently aware of is factually incorrect. Either you present a block device, which is a standard SCSI device on the remote host; windows, solaris, linux, or any other host OS that supports iSCSI/FC. OR, you present a file share via nfs/cifs, which is also the same regardless of host OS. There is no "zfs over IP", or "zfs over FC".

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

"That's not at all true. You can't remote mount a ZFS pool. If you present out a block device from a Solaris box, the remote box treats it like a standard SCSI device, regardless of what the remote OS is."

I did not know that. I thought you could create default zfs pool on that iSCSI device with one big fs which only uses the fs created in the larger pool on the host. That is what I meant by zfs over iSCSI. You can't do that?

So the best option is you make a ufs fs if you want to use solaris clients then?

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[saleenS281]

You can create a ZFS filesystem over the top of a LUN backed by ZFS, but it's no different than creating an NTFS or ext3 filesystem. The solaris host doesn't know that ZFS is running underneath the LUN coming off the server.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[mzs]

Oh my goodness, I thought that by now Lustre and ZFS had been much better integrated when Sun bought them. That is why I thought that with ZFS you could treat it like a CFS. I work for a federal lab and it was very hyped to us for about a year. I just googled and found this message:

http://lists.lustre.org/pipermail/lustre-discuss/2008-March/007006.html

Containing these nuggets:

---

Wed Mar 19 18:05:27 PDT 2008

> do you know if there is any chance that there be working lustre software for
> Solaris by the end of April?

Sorry, there is no chance of this at all. Due to integration issues
this is more likely to be available around the end of the year.

> > This is completely alpha code, you probably don't want to use it at
> > this time.

It refers to this wiki, not updated for a year now:

http://wiki.lustre.org/index.php?title=Lustre_OSS/MDS_with_ZFS_DMU

---

In fact all ZFS work is off of the roadmap in Lustre. I guess the promises made in 2007 did not pan out. It all seems even more likely dead now due to the Oracle purchase.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[Divebus]

The iTunes store uses Akamai. So it uses Linux, not OSX at all.

Really. So, why is it when I select a genre on iTunes, my traffic analyzer has pages of this?

Referer:http://ax.itunes.apple.com/WebObjects/MZStore.woa/wa/viewGenre?id=20&ign-mpt=c3%3DGenre-US-Main%2520Main-38-iTunes%2520STORE-Link_1-PopupLink_3%26amp%3Bv3%3DGenre-US-Main%2520Main-38-iTunes%2520STORE-Link_1-PopupLink_3&ign-impt=clickRef%3DGenre-US-Main%2520Main-38-iTunes%2520STORE-Link_1-PopupLink_3

Now, when I preview a song, I'll get some Akamai servers showing up but I still see plenty of
Host:a1457.phobos.apple.com stuff. It's not correct to say across the board that it's just Apple or just Akamai servers, for sure, but the entry point for most connections I see are HTTP/1.1 200 OK. Server: Apache/2.2.6 (Unix) and http://ax.itunes.apple.com/WebObjects/MZStore.woa/wa/triSplash?vi
ewName=21blah blah blah.

Now, you kids take back that troll mod.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[prockcore]

ax.itunes.apple.com and a1457.phobos.apple.com both resolve to IP space belonging to Akamai, and nmap -O says that they're both running Linux.

Akamai can run WebObjects applications on linux.

Re:Perhaps it will BE ZFS just not BE CALLED ZFS

[carton]

I think NFS is a good alternative to AFP. I use it at my Mac shop, and it works really well once you figure out the automounter tricks, which in short is, on Mac OS X 10.4 and 10.5 the automounter works oddly much better if you use 'net' and let it pick where to mount the share.

Once you get that worked out, Macs get along quite nicely with standard NFS servers which gives you a huge complicated market from which to draw.

There are some huge high-performance vendors in this space too like Bluearc and Isilon, and in addition to the already pretty intimidating (separate data/metadata cluster) NFS to SamFS/QFS gateway above, Sun is working aggressively (albeit slowly) on a new generation of cluster-backed (high-availability and not-limited-to-the-bandwidth-of-a-single-CPU) NFS stuff like pNFS, and NFS-to-Lustre gateways. It is not a mistake to make a commitment to NFS.

it'd be nice, though, if Apple would push all their netboot, LDAP, and software update cache tools as open source packages and get them integrated into CentOS or Ubuntu, the way they did with CUPS which works amazingly well. It's like they think they're doing some Microsoft Small Business Server thing with OS X Server, and it's just not on.

Re:For those who are wondering:

[wolf12886]

ZFS:

In computing, ZFS is a file system designed by Sun Microsystems for the Solaris Operating System. The features of ZFS include support for high storage capacities, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs. ZFS is implemented as open-source software, licensed under the Common Development and Distribution License (CDDL).

 

(sorry for the double post, should have included the quote from the beginning)

One less "feature"

[Lank]

With most of the emphasis on performance and stability, this was probably the one "feature" I was looking forward to with Snow Leopard. At $29 I'll still upgrade. Grand Central and OpenCL sound fairly impressive but I was really looking forward to a file system that never needed to be upgraded... I guess I'll keep on waiting.

Re:One less "feature"

[moosesocks]

I was really looking forward to a file system that never needed to be upgraded...

ZFS might be the holy grail of filesystems in terms of capacity, flexibility, and data integrity, which have traditionally been the limiting factors for filesystems. However, it's not particularly fast, and I'm sure that we'll come up with better ways to store data in the future.

If Apple have their own "ZFS killer" in the works, and choose to release it under a permissive license that's compatible with the GPL, they might very well be able to displace ZFS, given that the Linux community's refusal to support it has been an enormous thorn in its side.

Re:One less "feature"

[AccUser]

I was really looking forward to a file system that never needed to be upgraded... I guess I'll keep on waiting.

Heck, if it really never needs to be upgrades, I would say hang on in there until it works. It will be worth the wait. ;-)

Re:One less "feature"

[isorox]

given that the Linux community's refusal to support it has been an enormous thorn in its side.

Unfortunately it's incompatable with the linux kernel license (not to claim which is more free, or who's to blame). There's a fuse project, but fuse projects don't tend to go in places where zfs does.

Re:One less "feature"

[LingNoi]

Unfortunately it's incompatable with the linux kernel license (not to claim which is more free, or who's to blame). There's a fuse project, but fuse projects don't tend to go in places where zfs does.

Given how 90% of the comments on here are about how many problems there are with ZFS I don't think "unfortunately" is the correct word.

Re:One less "feature"

[mzs]

I am so liking ZFS on Solaris that having it in 10.6 would have been reason enough for me to by an new iMac (more for the use it instead of FAT32 between my Apple, FreeBSD, and Solaris boxes than anything else really). I currently have the lowest end model of PPC G4 eMac that officially supports 10.5 (Wow did I get lucky, six years ago I was really wondering if the $ premium on the 1GHz SuperDrive model was worth it). It looks that I can put off the purchase of a new iMac until 10.7 since Apple should continue offering security updates for 10.5 until then. Hopefully by then 10.7 will have ZFS support outside of FUSE and then I will gladly open my wallet (maybe I will even have the luxury of having to make the painful decision of whether the $ premium of the bluray writer is worth it).

I want a universal filesystem

[Anonymous Coward]

Which one can you mount on Linux, MacOS and maybe even Windows without precarious hacks, and with journaling, long filenames, and maybe extended attributes? So far FAT and HFS+ without journaling seem to be about the only choices. ZFS would have been it if MacOS and Linux both ended up supporting it, but now neither of them do (without precarious hacks!)... so Solaris is off in the corner by itself again. Bah humbug.

When I dual-boot my Mac (Linux & Leopard) I'd like to have the same partition for home directory on either system. A better FS for thumb drives than FAT would be nice, too.

The situation is utterly pathetic.

Re:I want a universal filesystem

[InterBigs]

Actually, the latest FreeBSD production releases also support ZFS pretty well. The most important parts of it, at least. So Solaris is not by itself.

Re:I want a universal filesystem

[JohnFluxx]

Why, it's almost as if Microsoft don't want to inter-operate. Ext3 is fully documented with viewable code, yet MS don't implement it. NTFS on the other hand has to be reverse engineered.

Re:I want a universal filesystem

[RegularFry]

In theory, I think UDF should work for this. I've not had much luck in my brief attempts, though.

Re:I want a universal filesystem

[dzfoo]

What about a pony?

            -dZ.

Re:I want a universal filesystem

[superposed]

I'm in the same boat. For years I've been looking for a file system can hold files larger than 2GB and can be mounted from Windows and Mac OS X (and maybe Linux). That would allow me to store all my work on one partition, and access it from Mac OS X, from Windows via Boot Camp, or from Windows inside Parallels or VMware Fusion. It would also allow me to transfer large files back and forth between my Mac and other Windows computers. I was hoping ZFS would be that file system.

The last time I checked (the middle of 2008), the only way to do this was via NTFS, and the only read-write support for NTFS on OSX was the MacFUSE NTFS driver, which was pretty slow.

I just saw that MacDrive 7.2 now allows Windows Vista x64 (my Boot Camp OS) to read HFS disks, so maybe I'll give that a try. There are also rumors that Snow Leopard's Boot Camp utility will include drivers for Windows to read HFS disks, so maybe that will help too.

Re:I want a universal filesystem

[Bandman]

If wishes were horses, we'd all be eating steak.

Re:I want a universal filesystem

[atmurray]

you're free to port ext3 to windows yourself if you want it that bad. besides, MS is having a hard enough time dealing with WinFS then have to worry about a third party file system :P

Re:I want a universal filesystem

[Ant P.]

UDF should work in theory (since it's the standard filesystem for DVDs), but Windows' brain damage as usual makes it useless as a general purpose FS.

Re:I want a universal filesystem

[drsmithy]

Ext3 is fully documented with viewable code, yet MS don't implement it.

What's in it for them ?

Re:I want a universal filesystem

[JohnFluxx]

Ext3 was ported to windows - you can download it for free. Of course the problem was that the API exposed for adding new filesystems is slow and has problems. The porters have complained about it, but got nowhere.

Re:I want a universal filesystem

[JohnFluxx]

Exactly how they think. They don't care about making it easy for users to have a decent cross-platform filesystem. They want lock in and control.

Re:I want a universal filesystem

[toby]

Being "off in the corner" with capabilities far beyond what anyone else offers doesn't sound like such a shameful place to me. If people won't educate themselves about what Solaris & ZFS offer, then their loss.

Re:I want a universal filesystem

[JohnFluxx]

Uh what? The specs for all the linux filesystems are completely open. People have ported ext3 to Windows, but struggle because of the poor API that Windows provides.
I can't see how you can possibly say that linux is guilty of taking-their-ball-home.

Re:I want a universal filesystem

[chefmonkey]

Why, it's almost as if Microsoft don't want to inter-operate...

You're comparing them to whom? Apple? Have you tried to mount an ext2/ext3 partition under OS X? The best you can get is some Panther-era third-party driver that causes frequent kernel panics on modern systems.

Re:I want a universal filesystem

[JohnFluxx]

I'm comparing them to Linux, which supports pretty much every filesystem to some degree, despite having to reverse engineer NTFS etc from scratch, and use hacks like using FUSE to mount ZFS to get around licensing problems etc.

Just because Apple also doesn't want to interoperate doesn't excuse Microsoft.

Re:I want a universal filesystem

[Hatta]

I really don't want Microsoft writing to my ext3 partitions anyway.

Re:I want a universal filesystem

[drsmithy]

Exactly how they think. They don't care about making it easy for users to have a decent cross-platform filesystem. They want lock in and control.

So.... Just like every other business then ?

Re:I want a universal filesystem

[mzs]

You might take a look at FFS UFS, form me it worked for NetBSD and FreeBSD disks I had to mount under Windows XP and Vista:

http://ffsdrv.sourceforge.net/

Supposedly it works with FFS from basically all the BSDs. The last time I looked UFS on Apple was essentially BSD FFS UFS. The headers look like it may deal deal with an Apple Partition Map as well, so it MIGHT work with that as long as you do not use GUID instead. Solaris UFS has made some changes long ago that make things different sizes than in FFS, so mounting FFS under Solaris is not possible in any way that I know of.

The other thing is that there are various journaling schemes for FFS and that as well as extended attributes and acls are fairly recent additions. I don't know how much of that ffsdrv nor Apple UFS support.

So now that I think about, man do I wish FFS would have been the best option, but I guess not. I guess cifs on top of whatever is sadly the best option these days.

Re:I want a universal filesystem

[JohnFluxx]

Not really. In most business there is a market pressure for standardization - customers want to be able to pick and chose components between different companies. Buy a TV from one company, DVD player from another, speakers from another, and so on.

However since Microsoft is in a strong monopolistic position, they are able to ignore the weaker pressure for standardization.
This is a fairly unique position - I can't immediately think of another company in a similar situation (I'm sure there are lots, but I can't think of any off hand)

Re:I want a universal filesystem

[shutdown -p now]

I'm in the same boat. For years I've been looking for a file system can hold files larger than 2GB and can be mounted from Windows and Mac OS X (and maybe Linux).

How about ext2? You can mount it with full read/write access both in Windows, and in OS X.

Re:I want a universal filesystem

[kindbud]

Why, it's almost as if Microsoft don't want to inter-operate. Ext3 is fully documented with viewable code, yet MS don't implement it.

MS don't need to. Ext2 Installable File System For Windows

Re:I want a universal filesystem

[Firehawke]

At least for USB drives, it looks like the successor will be exFAT (or call it FAT64 since that essentially IS what it is.)

Re:I want a universal filesystem

[drsmithy]

Not really.

How many businesses can you think of that aren't driven by a profit motive (ie: "what's in it for me") ?

In most business there is a market pressure for standardization - customers want to be able to pick and chose components between different companies. Buy a TV from one company, DVD player from another, speakers from another, and so on.

Sure. But what you want is to be able to buy the TV cabinet from one company, the tube (or panel) from another, the tuner from a third, etc, etc.

The OS *is* the component. You pick Windows, you get Windows, whatever Microsoft decides "Windows" is.

Re:I want a universal filesystem

[afidel]

UDF should also be worth a try. Vista and current versions of OSX support it read/write and it should support all the features you list no problem.

Re:I want a universal filesystem

[Eil]

That would allow me to store all my work on one partition, and access it from Mac OS X, from Windows via Boot Camp, or from Windows inside Parallels or VMware Fusion.

Most of us handle this by setting up a NAS that exports the filesystem as CIFS, which is supported by every major OS. Not only does this mean you can mount the filesystem from different operating systems, but also from different computers. And it makes backups a snap. The caveat is that this limits disk access speed to the speed of your network. If that isn't acceptable, then you really need a more complex (read: expensive) solution than either this or the one you propose.

Re:I want a universal filesystem

[JohnFluxx]

> You have to show them the signal _they_ understand: a sufficient quantity of extra customers who will use their software

If there was a profit reason to implement ext2 then they would have done so by now. You have gotten mixed up between user demand and profit.

Just because there's user demand for a decent cross platform filesystem does not mean that it would be in Microsoft's best interest to implement it. They want to keep people locked in and they want to make it difficult to make windows interact with other operating systems.

So I think its perfectly valid to 'beat MS over this'.

Re:I want a universal filesystem

[MarkRose]

Only if it's PINK!!! :D

Re:I want a universal filesystem

[otopico]

Just because a cat has kittens in an oven, you don't call the kittens biscuits

Re:I want a universal filesystem

[evilviper]

I want a universal filesystem Which one can you mount on Linux, MacOS and maybe even Windows without precarious hacks, and with journaling, long filenames, and maybe extended attributes?

UFS would be a good candidate, as Linux, BSD, and OS X include support for it, and a couple Windows drivers are available, though I can't comment on their reliability.

No, UFS doesn't have have journaling, but asking for an unseen technical feature is a bit like asking for a specific model of car... There's probably some feature you want, but you can't mentally separate the feature from the "journaling" technology you've heard in the same breath... If you're looking for fault tolerance, or fast recovery without waiting for fsck, that can be done better WITHOUT a journal, as in the case of UFS2 on FreeBSD, and ZFS on FreeBSD and [Open]Solaris. In fact UFS is easily the most reliable filesystem I've ever dealt with, and features like softdeps and UFS2 are improving the performance beyond any other general purpose filesystems out there now.

When removable drives are nearing the terabyte marker, exceeding the reasonable limits for FAT32, and NTFS still isn't open to 3rd parties, UFS seems likely to be the only option.

Integration issues

[henrikba]

The Known Issues and Features in the Works page for ZFS on MacOSforge explains the situation pretty well. Integrating ZFS into MacOSX isn't just a matter of creating a device driver. Time Machine, Finder, Spotlight and other core OS products needs to support ZFS features explicitly, since ZFS behaves a lot differently from HFS+.

Re:Integration issues

[An dochasac]

Yes, ZFS is very different from HFS+ (and that's a good thing). But ZFS makes Time machine much easier to implement, maintain and far, far more performant. Sun already had time slider in OpenSolaris last year and the difference between UFS and ZFS is at least as wide. Not to mention the fact that Apple throws heaps of money at its desktop and they only need to deal with drivers from vendors it controls. I have no idea why Apple would excise ZFS from its web exposure except to say that they're extremely good at hiding OpenSource technology under their own brand name. (BSD/OSX, Mozilla/Safari, VNC/Apple Remote Desktop...) Maybe they were unhappy with the patent protection clause in CDDL.

Re:Integration issues

[stefanlasiewski]

But ZFS makes Time machine much easier to implement, maintain and far, far more performant.

ZFS and Time Machine may have Snapshots and other similar-looking features, but they are very different codebases. It is probably difficult to adapt existing HFS utilities to a different filesystem.

Re:Integration issues

[A12m0v]

Webkit forked from KHTML long ago (2002?), they are now very different.

Re:Integration issues

[Anonymous Coward]

OS X 10.5 has an API to monitor file changes. Time Machine is built on top of that. The backup is built from new files and hard links to previous files and directories. Taking a zfs snapshot and sending it to another disk would do the same thing, but time machine lets you exclude directories.

Using zfs on the destination disk would be easier (just take a snapshot and sync up the deletes, additions, and changes).

Re:Integration issues

[saleenS281]

That list is 17 months old... I sure hope they've made some progress since then...

Re:Integration issues

[Anonymous Coward]

I'm a different AC and want to offer a more detailed point to that:

Some of the Finder integration issues had been fixed (eject, gajillions of volumes appearing) in earlier builds with the Carbon Finder. Then in a later build the GUI stuff for zfs disappeared from Disk Utility.app, that was a warning sign. Just now those of us outside of Apple got our hands on the newest builds. The Finder is a new Cocoa version and all the zfs command line stuff is missing. The macosforge zfs stuff has no 10.6 code on it yet. So until someone has the time to pull the drivers and tools from a previous build of Snow Leopard and see how well a zfs volume integrates with the new Cocoa Finder we won't really know about if those resolved Finder issues continue to be resolved.

Also in the earlier builds Time Machine was not able to use the zfs features. Nobody has had time for the latest build, and again with all the drivers and command line tools missing it's not trivial to check.

Re:Integration issues

[Seq]

Arguably true if Time Machine only does on-disk backups, which only solves the "oops, I deleted/changed a file" scenario. By default, TM wants an external disk locally (USB or Firewire) or through the network (time capsule), solving the more important "oops, I ran over my laptop with a truck" scenario.

To support ZFS snapshots on-disk and keep current functionality off-disk would mean maintaining two backends.

Also, I have not used ZFS, but are ZFS snapshots similar to LVM snapshots in that unassigned space is required for the delta? I'd like to see the genius bar describe that to the average Mac user.

Re:Integration issues

[tyrione]

Like hell Mozilla is hidden as Safari. WebKit is nothing like Gecko. And don't throw BS at it with KHTML/KJS is WebKit. WebKit dwarfs KHTML/KJS in depth and breadth. It's only now that QtWebKit is being merged into KDELIBS. How pathetic is that?

That would be a new feature

[code4fun]

Snow Leopard is about performance and optimization. A new file system would fall under new features.

Re:That would be a new feature

[zaajats]

Snow Leopard is about performance and optimization. A new file system would fall under new features.

There are other new features as well. Also, a new file system would be an update to the existing one, no?

(That doesn't mean ZFS will be there)

Re:That would be a new feature

[zaajats]

What I meant is that for 99% of the people a *new* file system doesn't create any new value.

e.g. - Time Machine is already an existing feature, improving the back-end by using ZFS is an unimportant change.

ZFS still needs more miles under the belt

[BlackSabbath]

I've played around with ZFS on the Mac a little bit. I've also played with ZFS at work (Sun UltraSPARC platforms) where we went from true believers to backing away rapidly (let's just say that there are certain Oracle workload profiles for which ZFS causes some massive performance hits especially when the disks are close to full).

I'm guessing that ZFS failed to meet at least one of (what I imagine are) Apple's criteria:
1. has to be simple to use
2. has to be rock solid

There's a good chance it failed at both. I'm not saying that ZFS is crap. Personally I think its a brilliant design, however it needs a bit more sunlight before its ready for the Steve.

Re:ZFS still needs more miles under the belt

[edmudama]

Any copy-on-write system needs a scratchpad area to be effective.

Were you unable to scale the disks a bit past your workload size?

Re:ZFS still needs more miles under the belt

[0x000000]

Okay, first and foremost it is well known that if you are running a database engine on top of ZFS you have to tune it to that specific database engine. This is well documented, and well described in the ZFS manuals, including steps to be taken to resolve these issues.

As for the performance degradation when the disks are close to full are being worked on, while this can cause issues (especially if you have a lot of snapshots) any IT worth their salt would not have let the disk get that close to full that it causes issues (I've seen this error once on my production servers, when the disk was at 95% capacity, I was brought in as a contractor). Replacing and upgrading disk capacity is as simple as pulling one drive from the RAID Z, placing a new one in, and letting it resilver, then pull the next one, until you have pulled all of them, after which you will get the full space the new disks can provide, so going from 1 TB drives to 1.5 TB drives will at the end of replacing all of them (so that they are now all 1.5 TB or bigger) give you the extra space.

As for 1, ZFS is extremely simple to use. gvinum from FreeBSD, or Linux's LVM are complicated, unnecessarily so, and 2, ZFS has so far proven far more reliable. It has been extremely fast, and has already saved a whole lot of trouble when a disk started failing by giving us a warning that ZFS reads were failing and letting us replace the disk before disaster strikes. Since we started using it in the last year we have had not yet had to resort to finding the backup tapes for a server because a disk went bad in Linux's LVM and bad data was written to other disks and files were lost.

I don't believe the issue is that ZFS is not ready yet, I don't think that Apple has had the time to make sure that everything fits in with their way everything has to work, certain features that HFS+ can offer are not possible on ZFS yet. Certain tools are relying on very specific HFS+ mechanics and workings (Time machine for example) which would complicate work to replicate that on ZFS.

While I was looking forward to seeing ZFS in Mac OS X, I doubted that it would be anytime soon, especially since it is a large undertaking making sure that the various parts of the system are all tuned for ZFS, this includes the way the OS caches, the amount of memory it can use for ZFS arc cache, and things along those lines. FreeBSD has slowly been working through those exact issues.

Re:ZFS still needs more miles under the belt

[BlackSabbath]

We never got a reproducible cause/effect explanation from the Sun engineers (which is one of the main reasons we started backing away).

Our particular problem seemed to occur when free-space shrank to below 20% and we had workloads with large numbers of connections doing lots and lots of very small write transactions in Oracle (using Oracle AQ as the backing store for our ESB/BPEL implementation). It wasn't 100% reproducible but seemed to be linked to those configurations more often that not.

Having said all that, we never used ZFS for production systems (we are far too conservative a company). We used it for dev/test/UAT environments where the ability to clone large numbers of test environments cheaply, quickly and with very little disk space cost was of great benefit. Its still used in some circumstances, just not all of them. Horses for courses.

Re:ZFS still needs more miles under the belt

[BlackSabbath]

I should probably expand on criterion 1 ("simple to use"):

ZFS has an absolute ton of features. Providing access to these in a meaningful and intuitive way would NOT have been easy. Its very hard to make a complex tool, "simple to use".

Nevertheless, I found playing with ZFS fun and strongly recommend it to those nerdier than the average nerd.

Re:ZFS still needs more miles under the belt

[BlackSabbath]

> you are running a database engine on top of ZFS you have to tune it to that specific database engine

Been there, done that.

> any IT worth their salt would not have let the disk get that close to full that it causes issues

I don't consider 80% a threshold which any FS should start to cause issues

> As for 1, ZFS is extremely simple to use

For unix admins perhaps. For the remaining rather large subset of Mac OS X users perhaps not.

> I don't think that Apple has had the time to make sure that everything fits in with their way everything has to work

Totally, 100% agree.

Re:ZFS still needs more miles under the belt

[lauwersw]

Sun changed to ZFS as the default file system in one of their last Solaris 10 updates. I can't believe they would do that if it wasn't completely ready according to them.

Re:ZFS still needs more miles under the belt

[isama]

Then the solution should be to make one easy utility for the common tasks, and when you need more you get the cli. (or another gui tool wich is more complex then the easy one.)

Re:ZFS still needs more miles under the belt

[asaul]

Read up on how ZFS and RAID-Z works. All data is checksummed - if you get checksum error, it will attempt to re-read the data. I am assuming your error rate is a random error, so therefore it will be read correctly on re-read and it will go on with life.

But yes, replacing one disk at a time does open you up to a failure window while it resilvers the new one. Of course, you can avoid that with RAIDZ2.

Re:ZFS still needs more miles under the belt

[asaul]

ZFS is managed by two commands - zpool and zfs. Both commands are so simple, straight forward and consistant its almost pointless wrapping them in something else.

Re:ZFS still needs more miles under the belt

[jlmale0]

Resilver disks to expand capacity? wth? No, to extend your ZFS pool, you just pop in new disks and extend the pool. Alas, doing this, you have to add multiple disks at a time in mirrored pairs or raidz sets. When I first started messing with this, I was really hoping to add disks dynamically to a raidz set, but this is not implemented. I fully recognize that this would be non-trivial to implement, but still the idea of adding one disk at a time, as you need capacity, is great for soho environments.

Re:ZFS still needs more miles under the belt

[0x000000]

Or you can replace every disk in your RAIDZ set so that you begin with 5 disks and end with 5 disks. You can also extend your zpool, but in that case you start with 5 disks and end up with 5+n disks.

I was just pointing out that on a RAIDZ it is very simple to go from smaller disks to bigger disks by allowing ZFS to do what it does best.

Re:ZFS still needs more miles under the belt

[chefmonkey]

Wait... what? You open by telling us that you have to perform custom tuning on the filesystem for certain applications, and later assert that "ZFS is extremely simple to use."

[cue the car analogy]

That's like claiming you have to open the hood on a car and tinker with the engine depending on what kind of road you're driving on, and then asserting that the car is "extremely easy to use." If you mess with your engine on a regular basis, it might seem that way -- but if you're a normal user, it's an unspeakable pain in the ass.

Re:ZFS still needs more miles under the belt

[Big Boss]

But you still need to buy 5 disks. When I upgraded my Linux based RAID5 I bought 2 disks and added them to the existing array. It took hours to resliver the array, but it worked fine. For enterprise applications, replacing all the disks at the same time is fine. Or just adding new disks. For SOHO users, that's not so good.

I won't argue about some of the advanced features of ZFS, but this is one area that could use improvement. And I really think that if it were available in Linux, someone would have already written it.

Re:ZFS still needs more miles under the belt

[fm6]

Oracle workload profiles for which ZFS causes some massive performance hits especially when the disks are close to full

I can't speak to the general performance issue. But I seem to recall that any file system performs poorly if there isn't a lot of free space.

Re:ZFS still needs more miles under the belt

[jlmale0]

True. But if one wants to increase the number of disks, expanding capacity, then it can't be done as incrementally as I'd like. Sure, I could just add 1 disk to your example, but there's no protection for that data. I could add two disks, and choose to mirror them; that works. But if I later want to increase the total by three disks, and I had mirrored disks one and two as an intermediary step, then that third disk has no redundancy. I have to back up all the data on disks one and two, delete the mirror and then create the raidz with all three disks. Likewise, jumping from 3 to 4 disks is similarly onerous.

I acknowledge fully, that enterprise operation means adding batches of disk at a time, and this isn't an issue. But in a SOHO environment, I can't grow as incrementally as I would like.

Re:ZFS still needs more miles under the belt

[kindbud]

(let's just say that there are certain Oracle workload profiles for which ZFS causes some massive performance hits especially when the disks are close to full).

Same results here. Oracle + Thumper + ZFS = unusable. Oracle + Thumper + traditional volume manager = good enough.

Re:ZFS still needs more miles under the belt

[Achromatic1978]

But yes, replacing one disk at a time does open you up to a failure window while it resilvers the new one. Of course, you can avoid that with RAIDZ2.

No. You can lessen the window with RAIDZ2, but you don't eliminate it.

Re:ZFS still needs more miles under the belt

[MauriceV]

The UER of enterprise SATA disks has reached 10^15 a while ago. See http://www.seagate.com/www/en-us/products/servers/barracuda_es/.

And SAS drives are soon arriving in TWO TB: http://www.seagate.com/www/en-us/products/servers/constellation/constellation_es/

Re:ZFS still needs more miles under the belt

[afidel]

HP has a SFF 15K drive with a sub 5ms full stroke access time (part 512547-B21). I think it's probably a 1.8 or 2" platter. Very good if you are worried about worst case performance for DB work. Oh and the RAID penalty you mention is of course why Oracle says SAME =)

Re:ZFS still needs more miles under the belt

[afidel]

What you described can be done with any decent raid controller.

Re:ZFS still needs more miles under the belt

[ArsonSmith]

But the engine is preset to run on normal roadways, streets and highways with acceptable performance. If you want drag race specific tuning you can up the horsepower by playing under the hood. If you need circle track you may want to make some changes to the tires and suspension. Dirt track there'll be other things you'll want to tune.

Re:ZFS still needs more miles under the belt

[jwhitener]

Early ZFS had some Oracle issues, but I think that all/majority of those are now patched. We've been running sun ldap, oracle db, tomcat, sun calendar, sun email on zfs in production, with ~24,000 unique visitors a day, and have had zero zfs related problems.

I'm not sure if your scale is far larger or something, but I see no performance difference between oracle on zfs and oracle on UFS/other.

Re:For those who are wondering:

[Omestes]

Hmm.. karma whore much?

I'm sure 99.9% of the people on Slashdot, who care enough to open the discussion know what ZFS is, and those who don't are perfectly capable of entering the term "ZFS" into Google.

But hell, lets see if I can do this too:

Apple:

Apple Inc. (NASDAQ: AAPL) is an American multinational corporation which designs and manufactures consumer electronics and software products. The company's best-known hardware products include Macintosh computers, the iPod and the iPhone. Apple software includes the Mac OS X operating system, the iTunes media browser, the iLife suite of multimedia and creativity software, the iWork suite of productivity software, and Final Cut Studio, a suite of professional audio and film-industry software products. The company operates more than 250 retail stores in nine countries[2] and an online store where hardware and software products are sold.

Sorry for trolling, have a six pack and a day off.

ZFS? What ZFS?

[commodoresloat]

There never was a ZFS. And Oceania was always at war with Eurasia.

I see no problem with that

[erroneus]

If something isn't "good enough" to make a solid product, then don't include it. This is how Vista got whittled down the way it was. The list of features that were pulled is longer than those remaining by my estimation.

Re:I see no problem with that

[AnalPerfume]

Then delay it, mark it as a target for the next release after this one. Review it closer the time to see if it is technically ready, if not, repeat the delay process.

Re:I see no problem with that

[profplump]

That's quite possibly what they've done -- you're confusing the marketing-controlled website with their internal development processes. Open-source projects post giant lists of milestones going years into the future because they're marketing to other developers (if they're thinking about marketing at all) -- but Apple follows a more traditional marketing plan and rarely publishes even vague feature lists before a product is launched, and certainly not more than one revision out. So while they may have removed ZFS from all future versions of the product I wouldn't take the removal from the website as direct evidence of that.

mod parent up

[commodoresloat]

tequila really burns when it comes out your nose.

Re:mod parent up

[vigour]

tequila really burns when it comes out your nose.

so do ham and cheese sandwiches :(

Re:mod parent up

[jonadab]

Well, duh. The nasal lining isn't designed to be immersed in alcohol.

Re:mod parent up

[commodoresloat]

Absolutely. One should really stick to cocaine when using that sort of delivery system.

Re:For those who are wondering:

[wolf12886]

I'm sure 99.9% of the people on Slashdot, who care enough to open the discussion know what ZFS is, and those who don't are perfectly capable of entering the term "ZFS" into Google.

Alright fair enough, I mean that's what I did, but alot of slashdoters like myself whould first grumble about there not being a link to said article in the story. So I figured near the top of the comments was the next best thing.

Also, I've already got excelent karma. Once they come out with a +2 Godlike-Karma-bonus you can legitimatly troll me for karma-whoring.

Re:Where does Slashdot get it's information?

[QuantumG]

Where does Slashdot get it's information?

From the firehose... which is filled by user contributions... like every other social news site.

Re:For those who are wondering:

[porl]

Slashdot

Slashdot, sometimes abbreviated as /.,[1] is a technology-related news website owned by SourceForge, Inc. It features user-submitted and editor-evaluated current affairs news with a "nerdy" slant.

(for those that got here by accident... you can't leave them out).

Re:They're waiting on iProd and iFPGA

[argiedot]

Nobody knows. See Ars Technica piece mentioning them. Essentially, someone opened up iPhone OS 3.0 and found references to two devices called the iProd and iFPGA in the USB Device Configuration plist, which is used (according to the article) to identify these devices on Mac OS X.

Re:They're waiting on iProd and iFPGA

[DES]

JFGI

We do

[theolein]

We use Mac OSX Server for our infrastructure. It's a royal PITA and I now wish we hadn't done it, but there have been a number of media companies in recent years that have moved to Mac OSX Server because all their clients are OSX.

My view is that Apple is just jealous of Microsoft and said to itself that if Microsoft can drop promised new features in Vista like the DB based file system, then why can't Apple drop ZFS? ;-)

Re:We do

[guruevi]

We use Mac OS X Server for our infrastructure as well. There is nothing wrong with it. It's just another Unix distro. The frontend is a little too simplified for most advanced uses (as it is geared toward the no-admin-here shop) but all-in-all once you get to it, it's about the level of Debian as far as stable goes.

I don't see why people have such a bad time setting up Linux/Unix systems (whether they be Debian-based, Red Hat-based or Mac-based). For the best results, hire an admin or otherwise talk to the vendor.

Re:We do

[otopico]

Off topic question. What about OSX server is causing the pain? I have been asked if it would be a reliable/easy replacement for a 50-70 user network (doing file shares/email/wiki/mobile and remote access for mostly Macs)and aside from garbage on the ol' internet, I can't find decent pros or cons from people actually using it.

I'd be happy to take it off to email otopico at that yahoo dot com

thanks

rebranding?

[dirtyhippie]

Is it not possible that apple is getting ready to rebrand ZFS as iFiles or something?

Err , Solaris == Unix

[Viol8]

Or at least , its one of the operating systems certified to follow all the unix requirements and hence Sun can use the unix name if they want. In fact many moons ago you'd see "SunOS Unix" at the login prompt.

Re:For those who are wondering:

[Anonymous Coward]

Wikipedia

Wikipedia is a free,[5] multilingual encyclopedia project supported by the non-profit Wikimedia Foundation. Its name is a portmanteau of the words wiki (a technology for creating collaborative websites, from the Hawaiian word wiki, meaning "quick") and encyclopedia. Wikipedia's 13 million articles (2.9 million in the English Wikipedia) have been written collaboratively by volunteers around the world, and almost all of its articles can be edited by anyone who can access the Wikipedia website.[6] Launched in January 2001 by Jimmy Wales and Larry Sanger,[7] it is currently the most popular general reference work on the Internet.

(for those who got freaked out and wondered were they were after they clicked your link).

KILL HFS+ WITH FIRE

[argent]

OK, when they updated UFS in Panther I was all ^_^ because I was tired of HFS+ turning up x_x, and then they decided to make Spotlight dependent on HFS+ and I was all o_O and half the guys on Slashdot were telling me that UFS was -_+ and ZFS was coming and they were all :) over that, well guys, what kind of emoticon are you mainlining now?

Re:KILL HFS+ WITH FIRE

[plus_M]

Â\(Â_o)/Â

In case you can't tell, this is supposed to be a puzzled-looking face with arms upraised in a questioning gesture.

Why doesn't slashdot support Unicode again?

Re:KILL HFS+ WITH FIRE

[argent]

Why doesn't slashdot support Unicode again?

Ø_ö?

Re:KILL HFS+ WITH FIRE

[mister_playboy]

I prefer them like this:

( . )( . )

ZFS or Btrfs

[r45d15]

Afaik Btrfs, which is roughly the Linux version of ZFS, has been started by Oracle (developers) and then embraced by Red Hat and alikes. So I'm wondering what are Oracle's plans about Btrfs after acquiring ZFS through Sun?

Re:For those who are wondering:

[porl]

hahaha touche

Snow Leopard *Server*

[R.Mo_Robert]

If you read the linked page (from Google cache), you'll see that this feature was slated for Snow Leopard Server, not the consumer version. I do not recall Apple ever advertising fll ZFS support as a feature for the consumer verison of 10.6, and neither does Wikipedia.

(Yes, consumer 10.5 does have read-only support for ZFS from the command-line; I imagine this would be still present in 10.6. In any case, it's not like this project is a secret, as Apple has released it open-source.)

I'm disappointed, but I'll get over it

[jocknerd]

ZFS doesn't make the cut for 10.6. Disappointing but there must be a reason. For one thing, 10.6 is about speed not features. So maybe ZFS still is in the works for 10.7. And 10.7 may be out sooner than we think. Maybe I'll invest in a drobo and give it a shot.

ZFS not ready?

[ggendel]

Well, I've been using ZFS for several years on several different machines with mixes of mirrored and RAID-Z configurations. Since that time, I've never lost one bit of data. It has survived power-supply failures, lightning strikes that fried the motherboard, flaky I/O cards, and human error. I understand that the implementation on Mac OS/X may be buggy, but it's not inherent to ZFS. I've several Macs doing time-machine to networked ZFS drives. It's definitely the filesystem I'd like to have everywhere.

Re:ZFS not ready?

[mzs]

"I've several Macs doing time-machine to networked ZFS drives."

How did you get that to work? Are you mounting a sparseimage file in OS X which you have exported from the Sun/FreeBSD box via nfs?

Re:ZFS not ready?

[ggendel]

You're right on the button. I created a sparse file for each machine image using diskutil so I could fix maximum size (I'd hate it to take over my entire 2.5 TB pool). The trick is to figure out the name that each machine wants, but worse comes to worse, you cancel it quick on the first sync if it's wrong and then rename the file and start it again.

Then I used the native CIFS service that comes with OpenSolaris for the connection. I started with Samba, but the native CIFS service had 1000X better throughput.

There is an option that enables mounting "foreign" disks for time machine. This may explain it better:

http://www.macosxhints.com/article.php?story=20080420211034137

Re:ZFS not ready?

[mzs]

Thank you for the very informative reply. One more question though:

Is there a reason you chose cifs over nfs?

Re:ZFS not ready?

[ggendel]

No particular reason, other than I use the same directory to back up the windows machines as well. I'm sure that the OpenSolaris NFS implementation would be fast or faster than CIFS. If you're using Linux or BSD I've heard that NFS has some occasional hiccups (stale lock issues) and performance problems. Take the previous sentence as pure gossip as I haven't seen or done any testing to prove/disprove it.

Re:ZFS not ready?

[mzs]

Yeah I have had some experience with nfs in on darwin, freebsd, and linux. In all cases it has been a good idea to fix the port that lockd runs on (nfs.conf or services files typically) and add firewall rules that let the IPs you need talk. The other services like statd seem to be fine though as is by just letting portmap pick on systems where it does dynamically.

OS X had automounting growing pains that seem to have gotten all worked out circa 10.4.

In regards to Linux, a long time ago there were issues I ran into where nfs over tcp was slow. Then the nfs over tcp got good enough somewhere in 2.2. There was (and probably still is) performance issues with half duplex and nfs over udp on Linux (I have not run half duplex in ages). The nfs code base also got pretty reliable around then as well, with the exception of 2.6.8.

With regards to FreeBSD I never had any trouble (there was that week when Matthew Dillon ran a NeXT fs stress test program and fixed a number of bugs though, I guess no one was being evil in my case) until I simultaneously went to FreeBSD 6.3 clients and Solaris 10 server. I was a bit disappointed that thre was little in the logs to clue me in what was up, but looking in tcpdump gave me an idea to try tcp and that worked fine.

Based on all of that history I now think that the best course of action if you want a good nfs experience is to fix the port for lockd and opening it in firewalls and to use nfs v3 over tcp. That seems to work the best on all systems. (Oh yeah for a while there v3 on Linux was strangely much slower than v2, but that got better in that same 2.2 time frame) v3 lets you support bigger files and is generally faster and is now well supported so that is why I tend to use that.

HAMMER? BTRFS?

[chrysalis]

I wouldn't be surprized if Apple dropped ZFS for BTRFS or DragonflyBSD's HAMMER, just because their license is better, because their performance don't degrade much over time and because Oracle has nothing to do with them.

Parent Wrong.

[toby]

Shame I just blew my mod points by posting.

But parent is completely wrong. ZFS root/boot is fully supported by Sun, and ZFS itself is used in production in thousands of installations.

Re:Parent Wrong.

[jwhitener]

root/boot wasn't originally possible with ZFS. I forget the version numbers, but it only arrived recently. We have some servers that, if I recall correctly, are less than 5 years old, but were setup with non-zfs boot because it was not possible at the time.

Mod -1: Almost entirely nonsense

[toby]

n / t

Nope.

[toby]

You don't know what you're talking about, re: ZFS. You can't duplicate it on "BSD/Linux". It is not the same thing as a Linux filesystem, nor a Linux volume manager, and the architecture of ZFS is considerably more powerful than these combined. The reasons why are public knowledge, why post without understanding them?

Re:For those who are wondering:

[toby]

Actually judging from the ignorant posts, 99% may be capable, but only 1% are actually doing it.

+1

[toby]

Amazing that this still has to be spelled out, isn't it.

And what's left is still crap.

[toby]

:-D

Re:And what's left is still crap.

[erroneus]

I was kinda hoping people would see past that fact to see that there are good reasons for omitting bad or otherwise "not good enough" code. I think with Windows, it's somewhat unavoidable to some extent because of compatibility concerns. I could go on and on about how it isn't entirely Microsoft's fault with the exception of the fact that Microsoft seems to support bad programming practices and should never have gone down the road of too much backward and "bug" compatibility.

The Dilbert Principle, Software Devel, filesystems

[Gary W. Longsine]

Please contemplate the reason that Google recently begged and pleaded that only developers download the *developer* release of Google Chrome for Mac and Linux, and begged people not to blog and whine and bitch about its shortcomings. (They were aware of its shortcomings. It's a work in progress.)

If you want to know more about filesystems, start here:
Filesystems @ Wikipedia (Hint: the blue words are links. Click on them to read and learn even more.)

If you want to know more about ZFS, start here:
ZFS

If you want to know more about designing and building filesystems, there is an excellent discussion here (this book should be required reeading for all software developers and systems administrators, regardless of what types of systems you tend):
The Design and Implementation of the 4.4 BSD Operating System

If you want to know more about the chief failing of the human intellect (our own limitations) start here:
Incompetent People Really Have No Clue, Studies Find: They're blind to own failings, others' skills
Personally, (just between you and me, the internet, and alien archeologists a billion years from now) I interpret this finding to be scientific evidence supporting The Dilbert Principle: "People are stupid." That is to say, we are all stupid about most things, most of the time. The trick is to figure out when you don't know what you're talking about, at which point you stop talking, and start reading or asking questions.

Complex and revolutionary software systems, like good food, take time. ZFS has tremendous potential. It might not be finished yet, or Apple might take the lessons learned from ZFS and use them in a different way (HFSEFK - HFS Extremely Fraking Cool).

ZFS is primarily a server file system

[Whatchamacallit]

ZFS is primarily a server file system. It's meant to be used with multiple disks. Now getting it to work with USB and Firewire drives is going to take some extra effort on Apple's part. HFS+ for Snow Leopard introduces some compression features which is how Apple was able to reclaim 6GB's of disk space on the Snow Leopard install. Much of that is stripping out non-Intel architectures, and some legacy subsystems/API's but the compression shrinks the OS foot print significantly.

So unless you are running a Mac Pro with 4 hard disks or an XServe you are not likely to be using ZFS anyway. ZFS is still a wonderful file system! It's fantastic on data center SAN's and large disk arrays! It's got some really nice features. But for Apple to implement it they need more time to refine it. As others have said already, many Apple applications have to be changed to take advantage of ZFS, etc. Sun's client base has professional Solaris sysadmins setting up servers and such. ZFS was designed to be easy for sysadmins not the average joe user. Apple needs to refine it and provide automatic behavior and build some easier to use management into Disk Utility for it. Then some monitoring tools, etc.

If we see it anywhere in the future, ZFS will likely be rolled out on the next big cat OS after Snow Leopard and only on OS X Server at first. Then likely, the next OS release may incorporate it on the client. I think they took a look at ZFS long and hard and from a design and engineering perspective put it on the back burner for the next OS cycle after Snow Leopard. Snow Leopard was about optimizing what they had and refining it and sharpening it getting it ready for the future. Focus was on 64bit with 32bit compatibility and to clean up the architecture by stripping out legacy stuff. Apple made a decision to not pursue ZFS at this time, that doesn't mean they won't go back and re-address it at a later date.

I personally, don't see the average Mac user gaining all that much benefit from ZFS unless they are a sysadmin and working with big storage. The average user with large storage needs is better off buying a Drobo device http://www.drobo.com/.

Re:ZFS is primarily a server file system

[carton]

no, bullshit. you are just sour-grapes-ing.

on OpenSolaris, ZFS is used to implement the Time Slider feature which is like Time Machine, only more proper. (space-efficient. roll-forwards and rollbacks are extremely fast. past clones are bootable. implementation is simple.) There's also an efficient incremental replication feature based on 'zfs send' and 'zfs recv' to handle the case of, for example, laptop user wants to back up the internal disk to a firewire external every night. They cannot seem to get their heads out of their ass to make the backup bootable without making a tiny edit to some stupid text file, but the foundation is really solid compared to the monstrous adhocness that is Time Machine.

Also OpenSolaris uses ZFS as part of the software update mechanism. The mechanism won't work without it. It's extremely useful because it lets you boot into a pre-update clone if something goes awry, or more likely if you encounter a bug (since all of open-source OpenSolaris is basically a beta testing pool for closed-source Solaris).

The snapshot/clone features of ZFS are extremely relevant to the desktop use-case.

Re:For those who are wondering:

[diegocgteleline.es]

One more doubt...

Anonymous Coward

"Anonymous Coward" is a term applied within some online communities to describe users who post without a screen name; it is a dummy name attributed to anonymous posts used by some weblogs that allow posting by people without registering for accounts.

Re:For those who are wondering:

[sootman]

Hypertext

Hypertext is text, displayed on a computer, with references (hyperlinks) to other text that the reader can immediately follow, usually by a mouse click or keypress sequence. Apart from running text, hypertext may contain tables, images and other presentational devices. Other means of interaction may also be present e.g. a bubble with text may appear when the mouse hovers over a particular area, a video clip may be started and stopped, or a form may be filled out and submitted.

(for those who got freaked out and wondered why they were somewhere else after they clicked your link).

Oh gosh....

[jotaeleemeese]

http://www.sun.com/storage/disk_systems/unified_storage/7110/specs.xml

You can even download a simulator.

Anybody that has been out of touch for one year or more with a technology should check his assumptions first before talking....

If Apple can't use the technology I think it is their loss frankly.

ZFS, HFS+

[Gary W. Longsine]

Filesystems often don't appear to be extensible, which is why Sun invented VFS. In any case, Apple's previously announced plan was to incorporate ZFS into Mac OS X Server, where a case-sensitive filesystem would be just fine with many potential users. Certainly a version of ZFS which directly incorporated some of these other HFS+ features might be useful on Mac OS X, and couldbe named ZFS+ or something.

Re:ZFS, HFS+

[ThePhilips]

Filesystems often don't appear to be extensible, which is why Sun invented VFS

I think you need to read the linked article yourself.

VFS serves completely different purpose.

As soon as you change presentation of files/meta information - even by mean of VFS - from point of view of user it is already different file system. Even if it would misleadingly named ZFS+, it wouldn't be compatible with ZFS: you might be able to mount it as ZFS, yet hierarchy/files wouldn't be readily accessible.

I'm frankly more interested to see how Mac OS X can run on UFS. Because if Apple made OS independent of file system features, then really there is no barriers to adoption of ZFS.

P.S. I might look here as ZFS advocate. In reality I'm Linux fanboi. Yet, as Mac OS X goes, anything would be better than archaic HFS/HFS+. Apple needs new file system sooner than later. E.g. I do not want to find that SSD in my MBP17 is a toast year later only because HFS+ can't manage it properly. And it is a fact that HFS+ (though better than NTFS still) can't be tuned to better support needs of SSD.

resource allocation

[Gary W. Longsine]

Right. Apple's going to take their fancy schmancy high powered kernel hacking filesystem writing developers (some of which were rescued at great expense and inconvenience from Sun, and Be, Slashdot's other favorite filesystem makers) and reassign them to work on Voice Memo for iPhone. That's why ZFS is behind schedule. Why didn't I think of that?

real world OSX use

[Gary W. Longsine]

" I mean, lets be honest no one really uses OSX Server for anything really mission critical that relies on it for the kind of storage capabilities ZFS would provide. Do they? Feel free to correct me with real world usage senarios of OSX Server ( I haven't heard of much)."

. By the way, have you heard of the iTunes Music Store? The iPhone App Store? Yikes.

Re:real world OSX use

[Bill, Shooter of Bul]

Ok, how many of those are going to switch to a different operating system due to the delay in zfs? ;) Now you understand the lack of pressure in getting ZFS in a widely released snow leopard.

Uhm... please mod parent "entirely f'ing wrong"

[Gary W. Longsine]

It's a widely known fact that Apple uses Mac OS X Server to host the iTunes Music Store. No, I'm not going to provide you with a link. Learn to use Google.

Re:Uhm... please mod parent "entirely f'ing wrong"

[prockcore]

As the meme says:

Netcraft confirms it:
http://toolbar.netcraft.com/site_report?url=http://ax.search.itunes.apple.com

The iTunes store runs on Linux.

Re:The Dilbert Principle, Software Devel, filesyst

[Hatta]

If you want to know more about the chief failing of the human intellect (our own limitations) start here:
Incompetent People Really Have No Clue, Studies Find: They're blind to own failings, others' skills

Does that imply that if you are acutely aware of your own failings, then you are competent?

Goodwill.

[jotaeleemeese]

They could get some of that.

karma whores vs. stats manglers

[Gary W. Longsine]

"I'm sure 99.9% of the people on Slashdot, who care enough to open the discussion know what ZFS is, and those who don't are perfectly capable of entering the term "ZFS" into Google."

Uhm... did you *read* this discussion? I'd say it's more like 50%.

BTRFS vs. ZFS

[DrYak]

So, no, Larry's company becoming ZFS owner ain't the reason Steve's company would drop it.

Unless you keep in mind that Larry's got his own filesystem under the hood : BTRFS was Oracle's GPLed answer to Sun's ZFS (BSD licensed).

So perhaps Oracle is thinking that developing 2 competing filesystems with the same feature-set is maybe too much ? (Specially since Oracle tends to target slightly more often Linux than BSD - and thus could make sens to put more resource into a file system with a GPL-friendly license rather than a files system whose license makes it incompatible with Linux)
And perhaps they would like to drop ZFS in the long term ? So suddenly there's less incentive for Apple to support ZFS.

Or maybe, indeed, it has nothing to do with Oracle acquiring Sun and perhaps ZFS is to Apple what WinFS is to Microsoft: an eternal "Sorry, we didn't have time to implement it in the current version of the OS, but we promise we will put it into the next iteration. Trust us, that time it'll be for REAL !" vaporware.

Re:BTRFS vs. ZFS

[Just Some Guy]

Sun's ZFS (BSD licensed).

Correction: CDDL licensed. If it were BSD licensed, it'd be in the Linux kernel by now.

Re:BTRFS vs. ZFS

[tao]

ZFS ins't BSD licensed; it's licensed using the (non-GPL compatible) CDDL. If it had been BSD licensed, I suspect it would've been supported in the Linux kernel a long time ago already...

I'm running Photoshop, you case-sensitive clod!

[jeffb (2.718)]

/>

Who's Larry?

[fm6]

If you mean, has Oracle management quietly told Sun to back off the ZFS evangalism, I kind of doubt it. It's hard to see why they would even care, at least not enough to risk getting caught doing something that could have nasty consequences — Oracle's acquisition of Sun still hasn't had federal approval, and illegally interfering with Sun's management would be just the thing to get it turned down.

The whole ZFS-on-MacOS thing is part of Sun's broader efforts to fight the marginalization of its technologies by open-sourcing them and then evangelizing everybody in sight to adopt them. This has happened not just with ZFS, but also with Solaris, the Sun implementation of Java, and even the Sparc CPU.

One aspect of this effort has been to push OpenSolaris and ZFS at desktop users. Pushing Apple to fully support ZFS (right now, they only provide a read-only driver) is part of this, as is a big push to get CS students and other hackers to download and use OpenSolaris on their personal PCs.

There's a certain amount of wishful thinking here. Solaris and ZFS do have very real and important technical advantages over their alternatives. But for a desktop user these advantages are pretty minimal. And to get them, you have to pay a big price in learning to use more complex tools and in not being able to participate in in bigger user communities.

Apple's response to Sun's ZFS evangelism was initial polite interest, but little positive effort over the long term. Not at all surprising: what use is ZFS to the typical Mac user? If servers were a bigger part of Apple's business it might be different.

Re:Who's Larry?

[fm6]

After a little research, I'm forced to admit that my comments on ZFS's limited value for desktop systems seems to be poorly informed. Here's a good summary:

Filter error: That's an awful long string of letters there. It's a **** URL!

Still, the interest in ZFS at Apple never seems to have gone beyond the "Hey, that's cool" phase. Probably they're just too committed to their own filesystem technology. They did put a lot of work into it.

Re:For those who are wondering:

[jhp64]

You left out the relevant part:

Slashdot

People that post comments designed to get more karma, for example mirroring a linked article or presenting a banal groupthink opinion or lame joke, are often referred to as karma whores.

I think this might be a marketing issue...

[rivaldufus]

In regard to the ZFS on a USB drive issue, I think it is probably a bad idea to market ZFS as a regular desktop filesystem - at least for now. It seems like it's more of a NAS/SAN (with comstar) replacement and not something to use with your USB drives.

How many here would be comfortable power cycling EMC Clariions or NetApp boxes arbitrarily? They have redundant power for a reason.

Personally, I've been burned so many times by people power cycling servers with RAID cards I get very nervous when I have to start working on a system that was hard power cycled. Is one of the disks now corrupt?

At any rate, you can deal with the USB issue if you're willing to remove the pool with the USB drive, then re-import it when you re-attach it.

Again, I'd say this is bad marketing. I'm likely to use FAT32 on small flash devices, but not on server filesystems. I'm willing to live with the issues ZFS has with removing a device from a pool as long as I'm using it on a server. They do claim that this will be resolved at some point. With as many people as Sun has laid off, is anyone surprised this is taking a while? I think it's less an issue of "arrogant engineers" (if any Linux zealots are saying this, they're being pretty hypocritical) and more of an issue of not enough man power.

Akamai is only a network

[raddan]

The backend, for the vast majority of their customers, is up to the customer to decide. I had the pleasure of taking a grad CS course with an Akamai engineer, and I specifically asked him about Apple, which is one of the customers he works with. He said Apple provides their own backend.

What about the other side?

[HumanEmulator]

Just playing devil's advocate: All the posts here seem to be trying to figure out what's wrong with ZFS to cause Apple to yank it out, but what if ZFS is fine and there's some big feature they're working on for HFS+ that they couldn't duplicate in ZFS?

I admit it's much more likely they just don't want to maintain full support for multiple filesystems, which is what they'd have to do because there's no way they're putting ZFS on iPhones and iPod Touches anytime soon.

Either way, the really telling thing is they aren't talking about ZFS in Mac OS X Server. If they had any plan for a ZFS future, it would start there much like the way HFS+ Journaling was initially a Mac OS X Server feature. (Introduced in OS X Server 10.2.2 and rolled out to non-server OS X in 10.3.)

Re:What about the other side?

[AnalPerfume]

I don't question whether ZFS was (or is) unsuitable either technically or legally for them to use. They have changed their minds which is also not an issue. I question the rewriting of history in deleting every reference to it, as though it never existed. Whatever Apple choose to use instead of ZFS will be (on their forums at least) seen as plan A, when ZFS was the real plan A. I don't understand the insanity which insists on rewriting history to show some unrealistic "we get plan A perfect every time" approach. Nothing works like that.

There is no reason for Apple to rewrite history when they can simply say "we have dropped ZFS for reasons we can't divulge, we are working on something else which we will announce in due course."

I know the APT (Apple Perception Team) are busy today modding any criticism as trolling, so feel free to mod this down like my other comment, rather than trying to explain why revisionism is a positive thing. I'd love to hear what Apple lose by leaving the ZFS stuff up.

Re:For those who are wondering:

[TheSpoom]

Comment

A comment is generally a verbal or written remark often related to an added piece of information, or an observation or statement. These are usually marked with an abbreviation, such as "obs." or "N.B.".

(Just in case you don't know what you're reading here.)

Re:For those who are wondering:

[prestomation]

You misspelled 'douche'

Re:Why do Apple insist on puling these stunts?

[AnalPerfume]

Whodathunkit? A story about Apple's control freakery in rewriting history, and a comment questioning the sanity of it gets modded as Troll, I'd be living in an imaginary world if I thought Apple's image control team wouldn't mod it down. Kinda enhances the point though.

HFS2 - Total speculation

[jriskin]

Maybe they will actually innovate and create something new. Personally I would love to see them go down a new path with consumers in mind. I would like to see something like what Drobo does for storage (at least in theory) make RAID seamless to end users. Have options like "Optimize this system for video production - less reliable data", "Optimize this system for general use", "Optimize this system for maximum space" those sorts of things. Then the system would automatically add volumes to the storage pool or allow them to be removed (if possible) in the most optimized fashion (striping, mirroring, etc...).

Obviously, do basic cleanup while they are in there (performance optimization, larger general limits, etc...).

Personally, if they dropped ZFS to do this I would be happy and say it was a good call.

Re:When did Apple promise ZFS?

[Roskolnikov]

Apple downplayed the inclusion of ZFS in leopard in what appears to be an egotistical tit for tat, Sun spilled the beans early to gain some publicity and Apple reacted in typical fashion;
as for promote, look at the google cache link I provided, scroll down to the bottom and see them promoting it. Just in case you missed it in the initial post:

http://74.125.47.132/search?q=cache:xc6veOk_OTQJ:www.apple.com/server/macosx/snowleopard/+Apple+ZFS&cd=3&hl=en&ct=clnk&gl=us

Bzzt! Thanks for playing: You Bet Your Sass!

[Gary W. Longsine]

You're looking at Akamai content caches. It doesn't seem to be a secret that the iTunes Music Store (purchasing engine, link handlers, content master archives) runs on Mac OS X Server, on XServer hardware. When the store first started, there was some Solaris in the mix, but that hasn't been the case for years.

Perhaps a closer look at ZFS is in order...

[NateTech]

Ask some folks running ZFS if they're experiencing problems... like "sorry, your data's gone" types of problems. Perhaps Apple's smartly just stepping back from the edge.