ZFS Confirmed In Mac OS X Server Snow Leopard

number655321 writes "Apple has confirmed the inclusion of ZFS in the forthcoming OS X Server Snow Leopard. From Apple's site: 'For business-critical server deployments, Snow Leopard Server adds read and write support for the high-performance, 128-bit ZFS file system, which includes advanced features such as storage pooling, data redundancy, automatic error correction, dynamic volume expansion, and snapshots.' CTO of Storage Technologies at Sun Microsystems, Jeff Bonwick, is hosting a discussion on his blog. What does this mean for the 'client' version of OS X Snow Leopard?"

Comments

What does this mean for 'client'?

[daveschroeder]

Nothing, in particular. It means that ZFS isn't going to be officially supported and/or promoted on client. But, since Mac OS X and Mac OS X Server are essentially the same OS with some different/additional pieces on the top of Server, and like other filesystems that were exposed via the GUI tools and supported on Mac OS X Server, but not on Mac OS X, in the past -- such as Mac OS Extended (Journaled, Case-Sensitve) -- it will likely be available via the command line tools, and usable by people savvy enough to work with other boot devices to format the volume in the desired fashion, etc.

Re:What does this mean for 'client'?

[larry bagina]

10.5 client includes readonly zfs support. The mac ZFS development is available here

Re:What does this mean for 'client'?

[Anonymous Coward]

Either you are violating your NDA or presenting a conjecture as fact.

Re:What does this mean for 'client'?

[Captain Splendid]

Hang on a sec. What's the point of running ZFS if it's that badly bloated, server or no server?

Re:What does this mean for 'client'?

[Goaway]

You should perhaps consider taking the internet less literally.

Re:What does this mean for 'client'?

[Captain Splendid]

I'm not. But since no one's refuted his claim yet, and I know jack shit about filesystems, I'd thought I'd stir the pot a little to get some more info on the subject.

Re:What does this mean for 'client'?

[Anonymous Coward]

The fact that no one has refuted it can be seen as proof enough that the claim is so preposterous as to render such preposterousness self-evident and therefore unworthy of refutation. Additionally, your ability to receive intellectual "hand-outs" is stymied by said lack of refutation. Ergo, your desire for more information will go unfulfilled. However, being the bleeding-heart that I am: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Memory_and_Swap_Space and, for future reference, http://www.google.com/

Re:What does this mean for 'client'?

[spun]

From what I understand, ZFS is fast not memory efficient. Minimum recommended system memory is 1GB, more is definitely better.

I'm no expert on ZFS, I just did a google search on 'zfs benchmark' and then on 'zfs memory usage' and pulled information from the first few results. Maybe someone who actually knows something can chime in?

Re:What does this mean for 'client'?

[Anonymous Coward]

Funny, I have it managing over a TB of disk space on a server with only 2GB of ram and plenty of applications and I don't have any performance issues whatsoever. You might want to try killing the talkoutofmyass daemon I do think it's using to many resources.

Re:What does this mean for 'client'?

[the_B0fh]

The moon is made of green cheese. Until someone refutes that, you can continue to think so.

Seriously though, zfs for osx is already available to be checked out and played with. Additionally, they hired one of the key zfs people and have her working on zfs for osx now.

I highly doubt it will suck, since, iirc, she was one of the people who worked on the test sets that SUNW^H^H^H^HJAVA runs nightly.

Re:What does this mean for 'client'?

[Anonymous Coward]

Speculation is that its not bootable yet, which is why it isn't in the client OS.

Re:What does this mean for 'client'?

[Anonymous Coward]

You might want to try killing the talkoutofmyass daemon I do think it's using to many resources.

Funny, I have more than 1 TB of talk coming out of my ass with no resource problems whatsoever. You might want to try killing your anecdotal daemon as I do think it's clouding your judgment.

Re:What does this mean for 'client'?

[Anonymous Coward]

It's not bloated, but it does use quite a bit of memory, as it caches very aggressively.

Which is good on a file server, not necessarily so much on a desktop.

Re:What does this mean for 'client'?

[Just Some Guy]

From what I understand, ZFS is fast not memory efficient.

Nitpick: it definitely likes a lot of RAM, but it doesn't necessarily use it inefficiently. Car analogy: a semi truck is fuel efficient, even though it's gas mileage is a lot lower than a sedan's.

Re:What does this mean for 'client'?

[spun]

That's what I meant. It is memory efficient from its point of view, not from the system's point of view. The point being, ZFS makes a memory for speed tradeoff that might not be the best choice for systems that aren't primarily file-servers.

Re:What does this mean for 'client'?

[hobbit]

I'm praying it will mean fewer messages like the following from the Finder:

"The disk "Such-and-Such" is in use and could not be ejected. Try quitting applications and try again."

Really, this sort of error message is an embarrassment. Try quitting applications?! Screw you! You're the bloody computer, tell me which fucking file is in use, and by which sodding application.

I've always assumed HFS+ is unable to provide such information, though I've never tried installing procfs to find out...

Re:What does this mean for 'client'?

[Anonymous Coward]

I'm praying it will mean fewer messages like the following from the Finder:

"The disk "Such-and-Such" is in use and could not be ejected. Try quitting applications and try again."

Really, this sort of error message is an embarrassment. Try quitting applications?! Screw you! You're the bloody computer, tell me which fucking file is in use, and by which sodding application.

I've always assumed HFS+ is unable to provide such information, though I've never tried installing procfs to find out... Why would you assume that? I mean, I would assume that HFS+ itself doesn't know what process is using a given open file, but only because that information probably isn't available at the HFS+ layer. Like many UNIX-a-like operating systems, MacOS X uses a VFS (Virtual Filesystem Switch) layer as an intermediary between applications and file system drivers. Information about which file is associated with which process is definitely available at the VFS level, regardless of what filesystem driver is handling the underlying file.

The real issue is that the Finder isn't trying to discover any information beyond the simple error code it gets back when trying to unmount a FS.

I agree they shouldn't be punting on this, but it's not as easy as your rant implies. It's very straightforward if the process holding an open file happens to be a GUI application and the filename is one the user recognizes because he saved it with that name, but what if it's a faceless background process with a cryptic name which has opened a file with a similarly cryptic name? The cause of that sort of thing might be something the user can easily understand and do something about (for example: tell Time Machine to stop an in-progress backup operation) but it's very hard to write software which, in a completely general fashion, correctly infers why a file is being held open and tells the user what to do about it.

Re:What does this mean for 'client'?

[Ilgaz]

the tool you need to see open files is: lsof , for example I open a pdf file from 'timemac' Volume and run:

quad:~ ilgaz$ lsof |grep 'timemac'
Path\x20F 185 ilgaz 15r DIR 14,14 68 9068665 /Volumes/timemac/.Trashes/501
AdobeRead 629 ilgaz 25r REG 14,14 4083738 5061210 /Volumes/timemac/melektaslak.pdf

The core Unix/OS layer of course provides that information. For some reason , Apple Finder doesn't ask that information to Core OS. Apple is almost fanatically conservative on Finder. That is why I purchased "Path Finder" after 10 mins of usage ;)

Re:What does this mean for 'client'?

[robogobo]

and, for future reference, http://www.google.com/ Thanks for that. I'm bookmarking it now.

Re:What does this mean for 'client'?

[ttfkam]

Why is that? Are desktop apps not disk I/O bound anymore? Processors have gone from Pentium 60MHz to 3GHz quad code 64-bit chips in 15 years. Memory has gone from 8-16MB standard to 1-4GB standard. Memory speed has gone from MB/sec to GB/sec. Hard drive capacity has gone from 1GB to 1TB.

Hard drive speed, on the other hand, has gone from 1-5MB/sec (if you were lucky) to 50-100MB/sec. In other words, while everything else has improved by at least a factor of 500-1000, hard drives are pushing somewhere between a factor of 20 and 100.

For the best performance for your system, you should absolutely be offsetting hard drive performance with CPU and memory whenever possible. An exception would be intense graphics rendering, but dedicated GPUs are siphoning off those cases more and more.

Bottom line, the most you can get out of your hard drive I/O, the better. Even a 30% CPU overhead would pay for itself when the hard drive is your limiting factor, and that goes for most systems, desktop or server. For laptops, it depends. CPUs draw a fair amount of power. Then again, so do hard drives. There, the answer is little more unclear and must be examined on a case by case basis. For your desktop and server though, take the CPU hit.

Re:What does this mean for 'client'?

[hobbit]

Even if the Finder only told the user the name of the app in question if it were a foreground app, that would still be a vast improvement. After all, "try quitting apps" won't get you very far if it's a background app...

Re:What does this mean for 'client'?

[hobbit]

Bless you Ilgaz. That will come in very useful.

I tried Path Finder, but it had too many kitchen sinks in it for my liking.

Re:What does this mean for 'client'?

[quadra99]

From what I understand, ZFS is fast not memory efficient. Minimum recommended system memory is 1GB, more is definitely better. Great for the common user :-) Tony Cognitive AB Stelvio Bokföring Lön http://www.ct.se/

Finaly

[bobwrit]

We can finaly fill up more than 8 TB on this FS. Anyone up to try?(with what?)

Re:Finaly

[Jellybob]

Our mail stores at work can fill 8TB quite happily (although they're on big network attached storage boxes, not ZFS).

Re:Finaly

[jandrese]

8TB is rapidly becoming "not that much stuff" these days. You can already buy 1TB HDDs, so we're just three doublings away from hitting the limit with a single drive (not to mention RAID arrays).

Re:Finaly

[Jor-Al]

I've had a 4 TB Raid 5 NFS for over 2 years now with another 3 TB one as backup. 8 TB is really not that much at all.

Re:Finaly

[Stormwatch]

No matter how much disk space you have: you WILL find a way to fill it.

Re:Finaly

[jabuzz]

At work our largest filesystem is a 20TB GPFS filesystem with HSM with at least another 50TB of migrated data on tape.

Frankly until ZFS gets cluster and HSM capabilities it is rather uninteresting.

Re:Finaly

[grub]

We can finaly fill up more than 8 TB on this FS. Anyone up to try?(with what?)

Rookie. My swap space is 8 TB.

Re:Finaly

[Daswolfen]

n00b... ... my pr0n folder is 8 TB.

Re:Finaly

[Skinkie]

Cluster capabilities it already has. But the point here is that is that for example iSCSI in this configuration is not yet supported that is a bummer. Next to this, there is only one point to terminate a controller in an active/standby setup. More cool features should be added to get ZFS to be really usable in a cluster scenario, especially with respect aggregation units and failover.

Re:Finaly

[fm6]

No, I need something big enough for my porn collection.

Re:Finaly

[Optic7]

Dang... does GPFS by any chance stand for "Ginormous Phrigging File System"?

Re:Finaly

[allenw]

I find it interesting in the 'last decade' sort of problems: root drives, RDBMS, etc. But unless it is linked with something like Lustre, I'm not sure if it is ready to take on the problems of this decade and Big Storage a la Google File System or Hadoop Distributed File System. Even a 70TB FS of the size you mentioned are starting to look tiny in comparison.

[For the record, I've used both ZFS and HDFS. Our largest HDFS--and we have multiple--has around 3-4PB, counting the space required by the 1:3 replication factor we use.]

Re:Finaly

[Captain Splendid]

You're the noob! With 8TB of frigging swap, GP's porn stash can obviously only be counted in Libraries of Congress!

Re:Finaly

[jabuzz]

Nope it's IBM's General Parallel Filesystem, and 20TB of spinning disk, with ~50TB of migrated data is small beer. I am aware of systems with in excess of 500TB of migrated data.

With clustered Samba nearly production ready, shared disk filesystems such as GPFS, CXFS, GFS etc. will become much more important. Imagine being able to yank the power cord on one of your Samba servers and watch as the clients just keep trucking and the load is transparently taken by the other servers in the cluster.

File systems that have HSM get extra brownie points.

Re:Finaly

[jabuzz]

News to me, double checking the Sun pages tells me that two or more servers cannot mount the same pool at the same time. It is allegedly coming with Luster 1.8, but it ain't here now.

Re:Finaly

[jabuzz]

Thats why there is HSM, the tape library at work is 1.5PB with room to scale with current tech to about 2.5PB. However that is a small tape library these days.

Re:Finaly

[somersault]

I remember reading about the level of storage or RAM aboard the Enterprise a few years ago, tried to find some similar info: http://www.memory-alpha.org/en/wiki/Petabyte this page claims that the human brain can store about a petabyte of information, that's pretty cool. I wonder how much a layered SSD the size of a brain would currently hold..

Re:Finaly

[Anonymous Coward]

File systems that have HSM get extra brownie points. Why would a file system have High School Musical? Do you want it pre-pirated? :-).

Re:Finaly

[sammy baby]

Lamer. 8 TB isn't enough to hold my collection of midget furry porn, let alone the whole shebang.

Re:Finaly

[Anonymous Coward]

The ZFS ability to tell which side of a mirror is returning valid data when one copy is damaged is interesting to me. How does GPFS detect errors in mirrored files and tell which copy is correct ?

Re:Finaly

[isorox]

We can finaly fill up more than 8 TB on this FS. Anyone up to try?(with what?) I've got 2 44TB 4U Servers for dumping stuff on. Naturally it uses ZFS.

"All features on this page are subject to change"

[TibbonZero]

It should be noted at the bottom of the page.
I was under the impression that they had initially hoped to include such in Leopard.

However, it isn't just Apple, Microsoft has been working on various structured file systems (WinFS through OFS and Storage+) for nearly 20 years with no shipped products

How will I benefit?

[The Ancients]

Ok, I'm reasonably technical, but not savvy with the intimate workings of a file system. What will this mean for the average user with an iMac or MacbookPro, when ZFS finally appears as the default FS of OS X? Will it be faster, more error-resistant, or...?

Re:How will I benefit?

[Cyberax]

It probably won't be faster (and may even be slower), but it definitely will be more reliable.

ZFS uses super-paranoidal checksumming which can detect drive problems in advance.

Re:How will I benefit?

[cblack]

Probably for an end-user workstation with a single hard drive, the main benefit will be resistance to errors. ZFS also has optional transparent compression so that could be useful as well I suppose.

Re:How will I benefit?

[countSudoku()]

You'll also be able to create a pool of drives that acts as a single drive, like you can with the RAID setup now, but far faster to setup. Growing your pools is a breeze and if they can tie TimeMachine into the zfs snapshots, my god, what can't we do?! Seriously, this will be a nice advanced file system for Mac OSX. We've been using it on Solaris for a year now for zone root/usr file systems, and zfs is AWESOME!!! Except that even Sun is not recommending we use it for zone root file systems until they hit update 6 of Solaris 10. Whoops! That's in November, so we're just sitting tight until they support Solaris root/OS zfs file systems. Then we upgrade. Then ? Then we profit!

Ob. Apple Joke referencing earlier /. artice:
Of course, the delay for the consumer OSX support of zfs will have to wait until they code in skipping backups of your iTunes library! ;)

Re:How will I benefit?

[Lally Singh]

Wow, it's such a major leap it's hard to describe.

Imagine having an external HDD on your mac. Whenever you plug it in, it automatically starts mirroring the internal drive.

Take atomic snapshots of your entire filesystem, send it over scp to back up your drive as a single file. Or, send over the difference between two snapshots as an incremental backup.

Have more than one drive, want mirroring? 2 steps on the command line.

Have a directory you really care about? Make it a sub-filesystem (this doesn't involve partitioning, etc, just a command that's almost identical in syntax and performance to mkdir) and tell ZFS to store 2 or 3 copies of it.

Have a directory you'd like auto-compressed? Tell zfs to compress it. New data to it is automatically, and transparently compressed. Completely transparent to the user and to applications.

And I'm just getting started. Trust me on this, google it.

Re:How will I benefit?

[MBCook]

For one thing it would make the implementation of Time Machine much simpler. No more directory tree full of hard links and such. If they put it on other boxes (like Time Capsule) they could unify the format (it uses a different storage method). Then you could pull the Time Capsule drive, stick it in your Mac, and be all set.

For servers, it has all the standard ZFS benefits (easy storage adding, redundancy, performance, etc).

For home users, it would let you simply plug a new drive in your Mac, press a button, and have it just add space to your main drive. You wouldn't need to specifically setup a RAID. No resizing. No "external drive" if you don't want it that way. Just buy a drive, plug it in, and it's all handled for you.

Re:How will I benefit?

[fishdan]

This is very informative

Re:How will I benefit?

[Anonymous Coward]

It will be more resistant to errors, sort of implements the features of Time Machine at the filesystem level (and should make Time Machine much faster), and makes it easy to pool storage together in the event Apple wishes to combine flash and platter disks on the same machines.

Re:How will I benefit?

[Lally Singh]

Yeah, self-reply. Some links on the matter:

ZFS: The last word on filesystems

Why ZFS for home

Why ZFS Rocks

ZFS: what "the ultimate file system" really means for your desktop -- in plain English!

Re:How will I benefit?

[cwingrav]

Figures you'd be posting replies to this story Lally.

Re:How will I benefit?

[lazyforker]

Unless you have multiple volumes in your device/environment you probably won't benefit much. For a brief description of the features and benefits of ZFS take a look at Jeff Bonwick's blog:
http://blogs.sun.com/bonwick/en_US/category/ZFS
especially the "Friday May 04, 2007 Rampant Layering Violation?" post. In the first paragraph you get a summary of the features, and after the mathemagical diversion you get a brief summary of the "layers" comprising ZFS and some of the rationale behind the design.
Or, of course, take a look at the Wikipedia article: http://en.wikipedia.org/wiki/Zfs#Features
I think the main benefits for clients would be the ginormous volume sizes, snapshot/clones, and variable block sizes. But I think the filesystem is aimed at servers with multiple volumes attached.

Re:How will I benefit?

[Wesley Felter]

ZFS uses super-paranoidal checksumming which can detect drive problems in advance. No, checksumming cannot detect drive problems in advance; for that you need SMART. Once your drive has been corrupted ZFS will kick in and prevent you from accessing any corrupt data.

Re:How will I benefit?

[CottonThePirate]

Compression! It is the one feature that I'm jealous of on windows machines. I constantly run Linux on older machines and which for a default file system that offered compression. I know hard drives are cheap, but not free. The same thing comes up on slightly older Mac hard drives all the time. 10GB was a standard laptop drive on older powerbooks and ibooks, these machines still run leopard fine, but it takes half their hard drive!

Re:How will I benefit?

[profplump]

What is it with you people and filesystem-level snapshots?

I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK).

If you really wanted to you could even write a script that takes no arguments other than a path name and automatically created a series of volumes of an appropriate size for the folder you selected, setup software raid to mirror them into a single device, mount the device with a compression filter, format it (with any file system) mount it normally, move the data over, drop the old data, rebind the mount point to the old path name, and update fstab. The only thing you miss here that ZFS may be able to do (I didn't check) is avoid closing the files that are moved.

I'm not saying the features ZFS has are useless -- I think they are great -- they just aren't all that new and exciting. They might be new OS X, or repackaged in a way that's easy to consume, but they are things that anyone with big disks has been doing for years.

Re:How will I benefit?

[Lally Singh]

Someone's gotta keep these heathens in check.

Re:How will I benefit?

[phliar]

Of course if you're not running a production server, you can install OpenSolaris on a PC and get ZFS root today. If your hardware is supported, OpenSolaris is much nicer than S10.

Re:How will I benefit?

[Cyberax]

SMART sucks. That's just a fact - very often it kicks in when your drive has failed.

Also, there are lot of real cases where malfunctioning drive can silently write incorrect data. ZFS will help you in this case.

Re:How will I benefit?

[Malekin]

The oldest laptop Apple supports running Leopard is the November 2002 TiBook, and that shipped with a 60GB drive.

Re:How will I benefit?

[Lars512]

For home users, it would let you simply plug a new drive in your Mac, press a button, and have it just add space to your main drive. You wouldn't need to specifically setup a RAID. No resizing. No "external drive" if you don't want it that way. Just buy a drive, plug it in, and it's all handled for you.

I'm not sure you'd want it to work this way for external drives. Will they be available at crucial parts of boot time when some important files are striped across them? Even if they are, you're basically unable to ever remove the external drive again. If there's a problem with the drive, all your data is lost. Probably the way these drives work now is better. Maybe mirroring onto an external drive would work ok, but it would then be an undesirable write bottleneck.

Re:How will I benefit?

[MSG]

I'd much rather have volume or block level snapshots ... All that without tying you to a single file system

It is not possible to make consistent block-level snapshots without filesystem support. If your filesystem doesn't support snapshotting, it must be remounted read-only in order to take a consistent snapshot. This is true for all filesystems. When they are mounted read-write, there may be changes that are only partially written to disk, and creating a snapshot will save the filesystem in an inconsistent state. If you want to mount that filesystem, you'll need to repair it first.

Re:How will I benefit?

[Anonymous Coward]

Step 1: "For home users, it would let you simply plug a new drive in your Mac, press a button, and have it just add space to your main drive. You wouldn't need to specifically setup a RAID. No resizing. No "external drive" if you don't want it that way. Just buy a drive, plug it in, and it's all handled for you."

Step 2: sometime later, unmount that drive, and have some (to you) random assortment of your files, possibly including files needed to boot your system, disappear or get damaged.

Step 3: ????

Step 4: profit????

Dropping the humor: I do not think this use case really makes sense for desktop systems used as such.

Re:How will I benefit?

[Anonymous Coward]

Sun is not recommending we use it for zone root file systems until they hit update 6 of Solaris 10

For that to work, you need a boot loader that supports zfs. This will come first in Solaris 10 x86 because they already have grub there. It's easier. For SPARC machines, it'll require new OpenBoot firmware that understands zfs.

Re:How will I benefit?

[jabuzz]

However missing,

  1. ZFS no cluster support, though perhaps coming later
  2. No DMAPI support so no HSM, and not on the roadmap

I am not sure what it is with all these ZFS fan boys, but it is missing some critical enterprise features as far as I can tell. Wake me up when it acquires them.

Re:How will I benefit?

[CottonThePirate]

Perhaps the oldest, but it only requires a G4 866 or better, which includes a lot of late model iBooks with 30G drives. I'm just saying I always run out of space on laptops (even with a newer 80G macbook). Lots of stuff can't be compressed, but I'd like those few extra gigs when it can be. I have a 1TB external drive at home, but defeats the point of a laptop to lug it around.

Re:How will I benefit?

[ArbitraryConstant]

ZFS uses super-paranoidal checksumming which can detect drive problems in advance. It won't detect them in advance. But, used appropriately, you won't care when they happen.

I'm not sure that's relevant to single-drive Macs though. It needs a mirror with a clean copy of the data to correct from.

Re:How will I benefit?

[The Blue Meanie]

For that to work, you need a boot loader that supports zfs. This will come first in Solaris 10 x86 because they already have grub there. It's easier.

Actually, GP was talking about ZONE root filesystems, which have absolutely nothing to do with the bootloader, since the zone runs on top of the underlying global zone. You CAN put a zone root on ZFS at the moment, but Sun neither recommends nor supports that setup.

For SPARC machines, it'll require new OpenBoot firmware that understands zfs.

And this is simply untrue, period, even for non-zone ZFS root filesystems. OpenBoot loads the next stage of boot code by reading raw data from blocks 1-8 of the chosen slice of the boot disk, and THAT is the code that needs to be able understand the filesystem that will be mounted as root (UFS, ZFS, or whatever). OpenBoot only needs to understand the disk label/partitioning and to be able to read the disk blocks. It already does that, so non-zone ZFS root will NOT require any modifications or upgrades to OpenBoot, just updates to the bootloader code that is written to the disk in blocks 1-8.

Re:How will I benefit?

[ArbitraryConstant]

I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK). ZFS shits all over LVM:

-Say I want to take hourly snapshots, and retain them for a month. When the parent data for a ZFS snapshot changes, ZFS merely has to leave the old data alone. OTOH, LVM must copy the block to every snapshot before it can change it in the parent. My hourly snapshots will quickly cause my disk to thrash to a halt with LVM and using much more space, while ZFS incurs a negligible penalty.

-LVMs allow dynamic partitioning, but they can't share capacity on the fly. If I delete a file on an LVM-hosted filesystem, that space becomes available to the filesystem but not all the others. Unless I shrink the filesystem, generally requiring that I take it offline for a while.

-Another layer could potentially handle checksums on LVMs, but in practice Linux can't do this properly by itself.

-ZFS can use other layers, there's just a substantial benefit to letting it run the show.

The only reason this won't turn out to be a huge disadvantage for Linux is that BTRFS will provide most of the same features. Layering can be a very helpful design tool, but there are times it becomes a hinderence. It's important to be flexible when there's benefits to integrating stuff into a single layer.

Re:How will I benefit?

[tknd]

For end user usability, one of the nicest features about ZFS is that things like fstab go away. On a freebsd box with ZFS, I setup a raidz pool across 4 disks. One of my controllers was giving me issues so I tried flipping around the disks in the various serial ata ports I had across 3 different serial ata controllers. ZFS comes back and detects the array correctly regardless of how the OS assigns the device names. Normally you would cause serious headache if you swapped around the drives.

Re:How will I benefit?

[Daffy Duck]

Be careful with "just buy a drive and plug it in". Unless something has changed recently, ZFS can't remove a device from a pool. So once you plug that drive in, you can never unplug it without a complete dump/restore - which means buying a whole other set of drives to do the backup to.

Re:How will I benefit?

[Anonymous Coward]

I'm not saying the features ZFS has are useless -- I think they are great -- they just aren't all that new and exciting.

Bah Phooey. Show me the file system, or LVM setup that has built in data integrity support. You cannot know what that means until you run a few ZFS pools and see the filesystem repair your data as it corrupts on disk. I always suspected HD's were crap, now I know for a fact.

ZFS is the best thing since sliced bread.

Re:How will I benefit?

[Joe The Dragon]

Faster to setup but real raid cards and fake RAID setup likely run faster.

Re:How will I benefit?

[Anonymous Coward]

SMART may suck, but it's better than what we had before. Only anecdotal evidence here...

A few months ago, I turned on my machine and was greeted by a window informing me that SMART errors had been detected on my main hard drive. I spent the next couple of hours copying over the last few files that weren't already backed up and then popped out to buy a new drive.

Without SMART, I would probably have been aware of the drive problems when the screen went black and nasty clunking/screeching noises started coming from the tower. And it's a bit late to save your email then...

Re:How will I benefit?

[MrMacman2u]

Actually S.M.A.R.T. is an amazing tool and is utterly invaluable in monitoring drive health... IF and ONLY IF you have the appropriate software (windows: google it, *nix: smartmontools) AND know how to read the resulting output.

The reason many people think SMART sucks and I say to check SMART manually is because 95% of drive manufactures set the threshold or "fail" values WAAAAY too high or low!

I use SMART constantly (about once every other week) to "check in" on how healthy my drives are and knowing how to read the values the software returns has saved my data many times. In fact, due to certain SMART values, I KNOW my Thinkpad hd is on currently on it's way to failing even though it is still working fine, for the moment. The SMART information has let me know it's on it's way out the door and therefore I have taken precautions to safegaurd the data on that machine and have the drive replaced.

Granted, SMART can't inform you ahead of time about sudden and complete mechanical or electronic failure, it can warn you if your drive is slowly the kicking the bit bucket. (With a small amount of know how until drive manufactures wake up and set more appropriate values)

Don't knock something you know nothing about! Kthnxbye!

Re:How will I benefit?

[Cyberax]

Maybe I'm unlucky, but I had three notebook HDs die on me without any warning. Even though I'm using 'SmartMon' program which should warn me about worsening drive condition.

Also, Google's on hard drive survey seems to come to the same conclusion: "One of those we thought was most intriguing was that drives often needed replacement for issues that SMART drive status polling didn't or couldn't determine, and 56% of failed drives did not raise any significant SMART flags"

http://www.engadget.com/2007/02/18/massive-google-hard-drive-survey-turns-up-very-interesting-thing/

Re:How will I benefit?

[MyDixieWrecked]

SMART sucks

There have been numerous studies showing that SMART failure predictions are frequently incorrect, saying that a drive is not going to fail when it is, or is late in reporting a failure.

"most intriguing was that drives often needed replacement for issues that SMART drive status polling didn't or couldn't determine, and 56% of failed drives did not raise any significant SMART flags (and that's interesting, of course, because SMART exists solely to survey hard drive health)"

source:

http://www.engadget.com/2007/02/18/massive-google-hard-drive-survey-turns-up-very-interesting-thing/

personally, I think SMART was developed by the drive companies to sell more drives. Frequently, admins (myself included) will replace a drive that they have a bad feeling about.

Drives are cheap enough that replacing a drive that possibly could fail is a trivial process.

Re:How will I benefit?

[Fweeky]

SMART sometimes works, very often it doesn't. Manufacturers have been progressively crippling it, to the point at which some barely even monitor anything, because they're perceived by marketing as being bad for business.

e.g. Seagate are one of the few vendors who are honest about ECC correction and seek error rates, and their SMART counters are correspondingly huge and read rather poorly (50-60/100 is a common value); you can even graph them and see the rates sweep up and down as the drive moves the heads over the platters every hour or so. Nobody else does this, and occasionally you'll see someone on a forum asking if it means their disk is failing.

Raw read and seek error rate on my Western Digital drives? 0, corrected values: 200/200. Right, I'm sure WD have magical drive heads which read every bit perfectly every time, and never miss seeking to a track, ever.

That's not to say SMART can't be useful, but as Google's disk failures USENIX paper demonstrates, they're not as reliable as one might hope.

Re:How will I benefit?

[MrMacman2u]

Again, as I mentioned in the beginning of my post, most drive manufactures set the threshold fail values to an extreme that, if reached, the drive has already failed for all intents and purposes. Your software cannot warn you if the drive does not report a failure in progress due to a threshold being set at an extreme value or '0'.

This is why I advocated learning what the "appropriate" SMART value ranges for your drive and manually checking the values. Because of this, I have only lost one drive EVER due to a sudden circuit board failure.

Re:How will I benefit?

[ttfkam]

Regular checkups can't prevent everyone from having a heart attack, but that doesn't mean you shouldn't get regular checkups. Even if you were notified of imminent failure only 44% of the time, that's still 44% more of the time than you would have without SMART.

Google's solution was to simply pull drives off the line after a given time interval. For most of us mere mortals on a budget, backups and SMART are better than nothing at all.

I dunno if I trust it yet.

[boxless]

I've lurked a bit in the opensolaris forums, and there's a whole bunch of scary things with this FS. Like the RAM requirements for starters.

Re:I dunno if I trust it yet.

[Anonymous Coward]

I would be grateful if you can follow up with more info on this? what sort of RAM requirements etc. (and any other issues)?

Re:I dunno if I trust it yet.

[cblack]

RAM settings can be tuned down (see ARC cache sizing). If you've just lurked on a list and not run it or read the tuning docs, you don't know and your vage sense of it being "scary" should hold little weight. I will say that the defaults for ZFS on Solaris are geared towards large-memory machines where you can afford to give a gig to the filesystem layer for caching and such. I don't know the absolute minimum RAM requirements, but I doubt they are inflexible and "scary".
I've been running zfs on solaris oracle servers for a bit and it is REALLY NICE in my opinion. They have also continually improved the auto-tuning aspects so you don't even have to worry about some of the settings that were often tuned even two releases ago (10u2 vs 10u4).

Re:I dunno if I trust it yet.

[ApproachingLinux]

a good place to start is probably the ZFS Best Practices page. the google text cache of that page is here. beyond that, try to google "zfs ram requirements".

Re:I dunno if I trust it yet.

[Vectronic]

Agreed, however it does seem (currently) to be directed at Servers, which tend to have 4GB's of RAM or more and dont really start and stop processes randomly like a Personal/Home computer.

As far as RAM requirements, ive seen various opinions ranging from 1GB to 2GB's as being a "sufficient" amount, but 4GB+ being ideal... and a Minimum of 768MB... if thats true, and if that is also including general ram use for other things, thats not so bad...

The only major limitation (according to Wikipedia http://en.wikipedia.org/wiki/ZFS#Limitations ) is the Quota management:

ZFS doesn't support per-user or per-group quotas. Instead, it is possible to create user-owned filesystems, each with its own size limit. Intrinsically, there is no practical quota solution for the file systems shared among several users (such as team projects, for example), where the data cannot be separated per user, although it could be implemented on top of the ZFS stack. Although personally I do not use any Quota management for anything, I could see that being a signifigant problem in many scenarios.

The rest of the limitations are par for the course in my opinion, most are similar to other file systems, and some are being worked on...

Re:I dunno if I trust it yet.

[MrMickS]

Solaris has used the idea of "unused memory is wasted memory" for a long time now. If memory isn't being used by applications then why not use it for file system buffering and cache? As long as it gets reaped by your memory manager when you need it for applications it seems like a good thing to do performance wise.

possible use

[MonoSynth]

The ability to hibernate your Mac with 16TB of RAM :)

Re:possible use

[Anonymous Coward]

And of course, 16TB should be enough for anyone...

Re:possible use

[nawcom]

Sounds like I'm gonna have to call Crucial and demand some 8TB so-dimms when they finally release it.

Re:possible use

[Anonymous Coward]

You say this as a joke, but it is not really that far-fetched. Modern big computers easily have hundreds of GB of RAM.

Add to that the fact that Apple is working on some mysterious tech to take advantage of multi-processing and factor in Xgrid for some neat transparent grid presenting itself as a single Mac.

Suddenly the old limit of 32 GB becomes a bottle-neck -- even 16 TB is not that much for a grid of 50-100 machines.

Of course you'd never hibernate such a grid...

Re:possible use

[Archangel Michael]

Is it me, or does 16 TB of Ram not seem so large?

Re:possible use

[joe_bruin]

The ability to hibernate your Mac with 16TB of RAM :) No one can afford 16TB of FB-DIMMs, there's not that much money in circulation.

Re:possible use

[greg1104]

Systems with a terabyte of RAM are not unusual in the government installations here in the DC metro area. Putting 16TB of RAM in a server will cost millions dollars right now, but it's by no means out of the question. See this SGI press release for a sample with 28TB of RAM.

Re:possible use

[Lars T.]

The ability to hibernate your Mac with 16TB of RAM :) No one can afford 16TB of FB-DIMMs, there's not that much money in circulation. Even at Apple's RAM prices it will cost less than a hour of non-war in Iraq. Far less.

Re:possible use

[TheGreek]

Putting 16TB of RAM in a server will cost millions dollars right now Nah. Just $1,228,800.

Re:possible use

[Anonymous Coward]

Whoosh. That was a joke about the price of FB-DIMMs.

Re:possible use

[Ilgaz]

If one buys from future Apple store, it will be 2,457,600 so, it is millions of dollars. ;)

Re:possible use

[TheGreek]

If one buys from future Apple store, it will be 2,457,600 so, it is millions of dollars. ;)

The dude said "will cost," not "could cost."

What does it mean for the client?

[argent]

Ask Apple:

http://www.apple.com/macosx/snowleopard/

does it run Linux?

[Anonymous Coward]

No but seriously, whats the deal with this being available for common distros? I understand its a sun developed thing, available for Solaris, but will it be available on Debian(Ubuntu) soon? Also if I add a new external HDD to my 'z-pool' and then lose it, do I lose data from my internal hdd as well as the external?

Re:does it run Linux?

[Wesley Felter]

No but seriously, whats the deal with this being available for common distros? It's not going to happen.

Also if I add a new external HDD to my 'z-pool' and then lose it, do I lose data from my internal hdd as well as the external? If you use RAID-0 (striping) mode you'll lose data.

More efficient backups.

[pavon]

One feature of ZFS is copy-on-write file snapshots, which allow you to "copy" a file, but the common portions of the file will be shared between the two copies, decreasing disk space.

This is great for backing up large files containing frequent but small changes. For example encrypted disk-images, parallels windows disk images, database files, the Entourage email box, or home videos you are in the process of editing etc.

Right now Time Machine creates an entire copy of the file each time it changes, making it unsuitable for backing up these types of files, and so you are encourage to exclude those files from backup. ZFS could fix that.

It could also make adding disk space more seamless, if desired. Slap on an external Firewire drive or even airport, click the "Add to storage pool button", and suddenly it just acts like part of your system drive. You don't have to worry about what is stored where.

Indeed.

[MsGeek]

Imagine a future version of the Time Machine which has multiple drives. One drive bites the big one. No worries! You just go to Fried or Office Despot or wherever and get a replacement. You plug the little sucker in and BAM! The drive gets "re-silvered" and your data is safe. If two of the drives go TU, same thing. Anyone know how many drives can fail at once in a RAID-Z2 before you are 100% SOL?

Re:Indeed.

[Wesley Felter]

Anyone know how many drives can fail at once in a RAID-Z2 before you are 100% SOL? RAID-Z2 can survive two drive failures; three failures will kill the pool.

Re:Indeed.

[hacker]

RAID-Z2 can survive two drive failures; three failures will kill the pool.

That's interesting, because the Linux implementations do not suffer these flaws. Look at the Drobo for a hardware device that implements exactly this, runtime.

Re:Indeed.

[Anonymous Coward]

RAID-Z2 can survive two drive failures; three failures will kill the pool. That's interesting, because the Linux implementations do not suffer these flaws. Er, what?

The entire premise of RAID-type redundancy is trading storage space for the ability to suffer N device failures before data loss. RAID-Z2 is roughly equivalent to RAID 6.

Are you trying to claim Linux implementations have some magical property of storing more data than is physically possible?

Re:"All features on this page are subject to chang

[QuantumRiff]

WinFS is almost ready... Its going to be here any day now. I heard its the base storage layer for Duke Nukem Forever!

Standardizing file systems

[failedlogic]

I don't know a whole heck of a lot of the technical details on ZFS. What I have read and understood, it sounds like what ZFS offers is something that every OS should include in its file system. Since, as I understand the BSDs and many Linux distros are starting to include (albeit limited/beta/alpha) ZFS support, and the long-rumored OS X inclusion being confirmed, could this be a universal file system for Operating systems? I would definitely like to see ZFS as a bootable Windows file system.

Say I have a portable USB hard drive or a dead motherboard in one system and want to retrieve the data off a hard drive. One computer has Windows and the other is Nix or OSX. Generally, the file system one could use that *should* work between Windows, Mac and 'Nix was Fat32. There are some issues with FAT32, the least of which is lack of support for large hard drives. The only other ways I can think of transferring the data are via Network or using a OS hook to read the data.

I just switched from Apple to Windows. I've been using an app to read my HFS+ file system on Windows to get data off the hard drive. It works well, but its not build-in. Nor is read/write NTFS access in other OSes. In any case, getting the data has been a bit of a pain. A standard file system I can just plug in a drive no problem would be awesome.

Re:Standardizing file systems

[larry bagina]

1. The GPL prevents ZFS integration (without a complete and total reimplementation of all the code... which won't happen since everybody prefers to write their own filesystem)
2. MS DOS/FAT is the universal file system for operating systems.

Re:Standardizing file systems

[DurendalMac]

Um, MS DOS/FAT may be universally read/write supported, but I don't think you can boot much other than Windows on it.

Re:Standardizing file systems

[shani]

I have a few Linux computers, running either Ubuntu or Debian, a Windows XP box I use for games, and a MacBook Pro. My girlfriend has a Vista laptop.

I was tired of not being able to save files bigger than 2 Gbyte on USB drives, so I recently looked at the possibilities:

• ext3 is nice and reliable, and there are ext2 drivers for Windows and OS X.
  
• HFS+ comes with OS X, and it works in Linux, but the standard way to run it under Windows seems to be via a $50 piece of software.
  
• NTFS comes with Windows, and it works in Linux (on Ubuntu you just plug in an NTFS drive and it works). On OS X you can use the FUSE NTFS-3G port to OS X.
  

Right now I'm using NTFS, because then I don't have to do scary geeky stuff on my girlfriend's computer. Left to my own purposes I would probably go with ext3/ext2 though.

I also include a small HFS+ partition that has the drivers for OS X so if you can install the software from the drive itself - sort of to future-proof the disks a bit.

If you need to plug in to random drives, then you are stuck with FAT or VFAT. If you are willing to install some open source drivers, then NTFS is the way to go. Who knows, maybe Steve will include NTFS-3G in OS X 10.6... :)

Re:Standardizing file systems

[foniksonik]

Get a copy of VMWare or Parallels and create a Virtual Disk from your windows machine... then use that on your Mac as a virtual machine.. voila. Now you can drag and drop files between Windows and Mac without any fuss at all. Bonus, if you have files that only open in Windows or need to be exported to a generic format for import to a Mac application... you can do it all on 1 PC (the Apple PC of course).

Re:Standardizing file systems

[foniksonik]

Oh wait... just re-read and saw that you switched from Apple to Windows... whoops.

I suppose you could go the other way, create a VM Windows on the Mac... just a new install would work fine... then copy your files over to the VM, copy the VM to your Windows PC... then mount it as a drive and copy to the Native Windows OS.

Re:Standardizing file systems

[Anonymous Coward]

The eventual replacement for FAT32 as a universal external disk format will probably end up being exFAT, sadly enough. ZFS is far too heavyweight for devices like, say, digital cameras.

At least exFAT fixes most of the issues that keep FAT32 from working well with today's data set. It's not the world's greatest file system, but at least it can, for example, support files >4GB.

Re:Standardizing file systems

[Fweeky]

With the CDDL covering ZFS, I know some people are hopeful that HAMMER will become ubiquitous.

Re:Standardizing file systems

[Ant P.]

No, UDF is the universal file system for operating systems.

Re:Standardizing file systems

[failedlogic]

Yeah, I had considered the options and decided to plunk down the $50 for the Windows software. OS X doesn't natively let you format ext partitions (there's probably a way after creating partitions during the OSX install, but hey, I'm just lazy). HFS and HFS+ tend to work better in OS X then UFS which is the other install option.

I just thought it would be a neat idea to through out the ZFS idea and see what others thought. I figure OpenSolaris might be the start of Sun letting go of some of the license terms.

RAID-6 vs. RAID-Z2

[stefanlasiewski]

It's interesting to note that the ZFS monitors don't seem to recover until the gentleman unplugs the failed drive. Is this a bug with ZFS, and has it been fixed?

RAID-6 & RAID-DP can also survive a dual-drive sledgehammer failure. The Linux MD Driver supports RAID-6.

How does Sun's RAID-Z2 distinguish itself from these existing implementations?

ZFS is great, but...

[K-Man]

Where is Mrs. Z?

Behind the times.

[Jane Q. Public]

If Apple really wants to start calling OS X a "modern" operating system, they are going to have to start supporting pluggable filesystems. SOON! Limiting to one or two (and, other than ZFS, not a particularly good-performing or attractive one or two), is extremely limiting. In fact, it is asinine.

Re:Behind the times.

[Anonymous Coward]

Err.. what makes you think it doesn't?

Apple has had information on developing them for years. Or did you think MacFUSE talked to the kernel using smoke signals?

solid state makes this moot

[Anonymous Coward]

Does it even matter ? With solid state storage poised to take off we don't need half of the fancy stuff to overcome hard disk limitations.

Re:solid state makes this moot

[the_B0fh]

are you one of those people who find some technical terms and latch on to them without understanding what it means?

Re:solid state makes this moot

[konohitowa]

I think the AC was referring to the encapsulation of polymorphic attributes when referencing latent metadata.

THIS:

[Jane Q. Public]

To "anonymous coward", a quote from your own link:

" ...it supports the FUSE specification well enough that many popular FUSE file systems can be easily compiled and made to work on Mac OS X..."

Excuse me, but that is NOT even remotely a "native pluggable filesystem"! That is an add-on from a third party (parties) that "can be compiled and made to work with OS X".

There is a pretty BIG difference, dude.

Re:THIS:

[Anonymous Coward]

I was referring to MacFUSE itself, not what it does -- it is a native pluggable filesystem. Without such support in OS X, MacFUSE wouldn't be possible. (Being an add-on itself is its goal: many interesting research-level filesystems are written to the FUSE interface, which runs code in userland, rather than to several OSes' individual kernel interfaces.)

But if you don't like that example, try Apple's own ZFS kext.

It seems apparent that you aren't a kernel programmer, but could you at least find one with even a passing familiarity with OS X before claiming it doesn't have a feature it obviously does have?

Re:"All features on this page are subject to chang

[Anonymous Coward]

I was under the impression that they had initially hoped to include such in Leopard. Nope, not full support. Leopard has read-only command line ZFS support. There were rampant rumors about it (including a Slashdot item), some suggesting that the 2007 WWDC keynote would reveal not only R/W support for ZFS, but that the default disk format was going to change to ZFS in Leopard. However, Apple's position was always to have read-only support in Leopard (allowing for some functionality when 10.5 is considered a legacy OS, and ZFS is common), knowing that read-write support would be coming in a future version. There has also been a beta ZFS read-write driver for Leopard since just after last year's WWDC when ZFS support was announced.

Relative Metric.

[bill_mcgonigle]

There are some edge cases in ZFS, but compared with HFS+ - well, "Invalid leaf node".

No, license issues

[bill_mcgonigle]

will it be available on Debian(Ubuntu) soon?

Not until OpenSolaris and Linux are both GPLv3.

ZFS is patented and patent protection is only conferred through use of CDDL'ed code, which isn't compatible with GPLv2. A cleanroom implementation of ZFS, besides being redundant, has no license to use ZFS's patented technology. Whether Sun would sue a linux dev over this is a separate issue.

BSD implemented a Solaris compatibility layer to use the CDDL code directly, but their license isn't incompatible.

Jeff and Linus have visited lately - I think Jeff was just helping him hook up a new gas grill, but maybe something work-related was discussed. :)

Regarding checksums

[warrax_666]

One of the major points of the ZFS checksums is that the checksum for block X is stored in the block that points to X. In addition to ensuring that X is written properly is also ensures that writes actually go to the correct blocks.

Re:I don't have to be...

[Anonymous Coward]

Then you must be using the term "pluggable filesystem" differently than most other people. OS X has kernel support for loading dynamic modules (plugins) containing filesystem logic at runtime, and Apple provides the necessary documentation for developers to implement them. There are modules available for download from both Apple and third parties to add support for various filesystems to the version of OS X you're running right now. Hence "supporting pluggable filesystems", in exactly the same way as most other modern OSes.

If not that, then what exactly do you mean?

Re:"All features on this page are subject to chang

[Svartormr]

Hey, *I* heard that they now think WinFS won't be ready in time and won't be good enough, so they're writing their own DNFS.

Re:I don't have to be...

[konohitowa]

Good luck finding that out. I read this thread repeatedly and I can't for the life of me figure out what she's after.

Re:"All features on this page are subject to chang

[mzs]

Uh no:

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

You can download it (also there may or may not be a R/W version on the Apple developer site) and pretty much everything even snapshots work.

Here are the known issues:

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

The real big issue the last time I tried it is that Finder does not work too well with ZFS and you get gajillions of what look to be mounted discs.

Re:I don't have to be...

[Jane Q. Public]

Okay, then, would the phrase "out of the box" clarify matters for you?

Perhaps I could have made this clearer, but from the context I thought it was obvious that I was referring to native, out-of-the-box support for pluggable filesystems. NOT some kind of add-on you can get later and have to compile yourself, then tweak a bit before you can even get it to work (which is what all the examples here have stated they require).

Re:"All features on this page are subject to chang

[toby]

The killer features for ZFS have nothing to do with "structured" filesystems; ZFS is essentially POSIX.

Everybody has their own favourites:

• uncompromising data integrity through checksums and transactional copy-on-write; high durability using scrubs and redundancy
• cheap snapshots
• manage filesystems as simply as directories
• pooled storage for manageability
• very high throughput for certain workloads
• etc.

While snapshotting and COW are not entirely new, many of its features are not available elsewhere, though initiatives such as btrfs for Linux may eventually cover some of them.

Plenty more information out there on Sun's web sites (ZFS isn't Apple, nor vaporware, it's out there in production at thousands of sites and has been available in Solaris 10 and OpenSolaris for a few years.)

Also, a version of ZFS was actually included in Leopard, but without GUI access (AFAIK).

self-healing

[toby]

Once your drive has been corrupted ZFS will kick in and prevent you from accessing any corrupt data.

If you have redundancy (such as mirror or RAIDZ), ZFS will also repair the data.

Nothing new, eh?

[toby]

What other filesystems do end to end checksumming and self healing, on any operating system today?

Home Users = Digital Hub

[toby]

As Apple has been (over)selling for years: Your Mac is your Digital Life.

Home users should be much more concerned about data durability and integrity than performance (not that performance would ever be bad).

A physical photo album will last a couple of centuries. Your hard disk may not last 2 years. And there's only 1 of them in any consumer Macs.

People are going to lose their digital snapshots, their unfinished novels, their emails and love letters, because nobody understands the inherent fragility of digital media and that hard disks are disposable consumables - even professionals.

Re:Home Users = Digital Hub

[Lars512]

...and Apple has really come to the table with Time Machine, making backup happen for the masses. Perhaps its reasonable to assume that if our computer crashes, we lose one hour worth of non-recoverable work. That's the promise if you use Time Machine with default settings.

They could do better by making mirroring standard in desktops, but in laptops they're probably on the money. They could do better by perhaps using zfs for block level backups rather than file level, but what they have now is far better than nothing.

sux 2 b u

[toby]

I just switched from Apple to Windows.

Re:sux 2 b u

[failedlogic]

Hardy, har, har. In case your inquiring mind wants to know. I had an iMac G5, needed to sell it for cash and then bought a new, faster PC for significantly less than a new iMac. I'll consider getting a mini at some point in the future, OS X is nice to use, but the hardware is pricy and I couldn't afford it.

Re:sux 2 b u

[catmistake]

Even though its against the EULA, Apple has shown by their lack of doing anything to stop it (and they pretty much go ape shit about the stuff they do care about, like secrets and NDAs), no one is stopping you from running OS X on your new box. Welcome to Hackent0sh!

you find HFS+ slow?!

[toby]

Care to provide comparative benchmarks?

Re:I don't have to be...

[Anonymous Coward]

Okay, then, would the phrase "out of the box" clarify matters for you? Meaning you want Apple to ship more filesystems with OS X? I can understand wanting that, but it seems odd to claim it's a requirement for a modern OS. Usually it's better to provide support for loadable filesystem modules, no matter how many filesystems you ship yourself, so that third parties can add whatever you don't do yourself. Even Linux's wide range of filesystems are mostly supplied by third parties, not by the primary kernel maintainers.

Perhaps I could have made this clearer, but from the context I thought it was obvious that I was referring to native, out-of-the-box support for pluggable filesystems. NOT some kind of add-on you can get later and have to compile yourself, then tweak a bit before you can even get it to work (which is what all the examples here have stated they require). Apple's ZFS is provided in binary form. The installation process is manual because it's developer/alpha quality, and you're replacing the read-only ZFS support that ships with 10.5, but no compiling is required. This is what will eventually ship with Snow Leopard.

MacFUSE provides installable binaries. Once installed, you can use any of the FUSE filesystems that their developers provide in binary form for OS X, such as sshfs or NTFS-3g.

If you install MacPorts, you can choose from their collection of FUSE filesystems, without dealing with MacFUSE etc yourself. This is similar to using package repositories on popular open source OSes.

Hell, even Apple's developer demo MFSLives ships with PPC binaries, although I haven't the foggiest idea what anyone would practically use it for.

All without compiling or tweaking anything.

The bottom line is that Apple does, in fact, provide native, out-of-the-box support for pluggable filesystems in OS X. Apple does not provide a wide variety of filesystems itself, but neither do most other OSes, and that's a separate issue from support for pluggable filesystems. After all, there's no need for pluggability if you ship all the filesystems yourself...

Re:I don't have to be...

[Anonymous Coward]

Okay, then, would the phrase "out of the box" clarify matters for you? Perhaps I could have made this clearer, but from the context I thought it was obvious that I was referring to native, out-of-the-box support for pluggable filesystems. NOT some kind of add-on you can get later and have to compile yourself, then tweak a bit before you can even get it to work (which is what all the examples here have stated they require). Um... Do you have any idea what pluggable means? It sounds like you're confusing filesystem software with an external drive that you can "plug" into a machine via USB or FireWire or eSATA or what have you. In the context of this discussion, since it's talking about a loadable kernel extension filesystem (ZFS), pluggable would mean a kernel extension, not the ability to attach a random drive to a machine and have it just work. Given that working definition, Apple does plainly support kernel extensions to add new filesystems quickly and easily, regardless of whether or not the user would have to compile the software to get it to load properly. As for what filesystems are supported natively without having to add your own kernel extensions, there is a wide variety already supported. I don't know what you could possibly want that isn't a niche filesystem. Further, since it's clear you're the asinine one here and don't have a clue what you're talking about, don't make assumptions about what's prudent (or not) for any modern OS.

ZFS is fast, but not lightweight

[OrangeTide]

It's complex and fat. but it beats out a few other filesystems on I/O performance. But processor utilization goes up and memory usage goes up.

Re:ZFS is fast, but not lightweight

[spun]

The benchmarks I saw showed that it doesn't just beat out a few other filesystems on I/O performance, it beats them all like a rented mule. By an order of magnitude or more. Sure, processor utilization and memory usage go up, but what else does a file server need to be doing besides serving files?

Re:ZFS is fast, but not lightweight

[OrangeTide]

doesn't beat WAFL in any significant way or the file system I worked on that I cannot disclose.

Re:ZFS is fast, but not lightweight

[spun]

Yeah, but I never saw it benchmarked against breakfast foods or mystery file systems that can't be named, so I can't comment on that. :P

Re:ZFS is fast, but not lightweight

[OrangeTide]

hehe.. very funny, WAFL is what is used in NetApp filers. You can read the patents on it and get a pretty good high level idea of how it works, the patent documents lays it out in pretty easy to understand terms. As for the mystery filesystem (starts with a D), it's like XFS but has more features to make it worth comparing to ZFS. The performance is similar to XFS too (a little better when it can hold transactions in NVRAM).

Even XFS is on par with ZFS (with lower cpu utilization) for nonclustered performance. XFS is so close to the theoretical maximum performance of a raw unclustered disk group (when tuned for the workload) that there is no "an order of magnitude or more" in those cases. When get get 99.5% of the raw disk I/O performance you're not going to reach an order of magnitude by making it .5% faster :)

Of course for a distributed cluster of disks the free version of XFS is nothing compared to ZFS, because XFS can't even really do clustering. And few people benchmark SGI's commerical CXFS, despite my experience with XFS even I haven't used CXFS.

Also it's hard to compare most filesystems to ZFS because most filesystems that have RAID just live on top of a hardware/software RAID implementation. XFS (and others) do a little bit of optimizations when they are on a RAID, but it doesn't really reflect in the performance numbers in a major way. ZFS has the advantage of RAID-Z, which is faster(usually) and far more flexible.

ps - I like to think of XFS as the base line of what a good filesystem should be, and you're either better than XFS or worse. I'm not trying to claim XFS is the fastest filesystem in the world or anything. Although if tuned for your workload the performance is quite impressive, when not tuned there is a lot of head scratching why all your RAM is gone and your performance is worse than FAT.

Re:ZFS is fast, but not lightweight

[spun]

I'll have to check out WAFL, sounds interesting,

Good point about tuning. In high end situations, tuning for your particular workload is often more important than choice of file system.

Re:ZFS is fast, but not lightweight

[hjf]

nice troll, but it beats the crap out of it... in price.

Delta-based backups?

[Jay L]

(If this question isn't relevant to ZFS, please just yell at me.)

I've been using CrashPlan lately for backups, which, AFAICT, is effectively the same as a copy-on-write system; they store some type of "rolling delta" so that only changed data is rewritten to disk.

And that seems really cool. But one thing keeps nagging at me: Don't copy-on-write/delta based systems prevent you from safely growing a logical volume beyond the limits of a physical volume, short of massive duplication?

Let's say I had a 500GB physical drive rooted at /source, and I'm backing it up to a 1TB physical drive /media/backupa, keeping backups forever. The first copy is 500GB; great. Over some period of time, every byte of /source changes, so that I have another 500GB of deltas. Oops, /media/backupa is now full.

No problem; I can add another 1TB physical drive at /media/backupb, and combine them into logical volume /media/logical-backup. Except that either (a) /media/backupb has to ALSO hold the first 1TB of data, which means it's full, or (b) any backup that depends on deltas stored on /media/backupb also must depend on /media/backupa, which contains the ancestor of those deltas.

So maybe I just make /media/backupb a mirror of /media/backupa; now I have two copies. I then add a third 1TB drive, /media/backupc, and make it part of /media/logical-backup. Now I'm cool - assuming I don't lose both /media/backupa and /media/backupb at once. Except that, as we keep expanding /media-logical-backup, the number of failure combinations we can withstand keeps going down, as the number of cross-dependencies increases.

Am I missing something?

Re:Delta-based backups?

[pavon]

This is related to ZFS, but it sounds like you aren't familiar with how RAID works, and since ZFS uses the same fundamental principles for redundancy, I'll start there.

Both RAID and ZFS use striping and parity checking to distribute blocks across the devices - you don't mirror an entire disk when adding devices. Say you have a RAID-5 with N disks. For each stripe (chunk of the disk) you store original data on N-1 disks, and on the remaining disk you instead store a checksum of the data in the first N-1 disks.

Then when you loose any one disk, you can recover the data what was on that disk by calculating the checksum from the remaining disks (with a checksum Z = A + B + C, it is just as easy to recover B = A + C - Z, as it is to recover Z). This single parity gives you a storage space of N-1 of N disks, and allows for a single disk failure. It also means that every write operation has to write to two disks, rather than just one.

There is also a double-parity scheme, RAID-6, that allows for two simultaneous disk failures with a storage space of N-2 of N disks. There are also schemes that give no-redundancy - just a logical pool of data (RAID-0), or complete redundancy - mirroring (RAID-1). ZFS is pretty much the same, but is more flexible when it comes to adding drives of different size. RAID-Z is ZFS's single-parity scheme, and RAID-Z2 is its double-parity scheme.

Furthermore, ZFS's snapshots don't use deltas. Each file contains a list of all the blocks containing its data. When you create a snapshot, it just creates a new file entry that points to the same blocks as the old file. If one of the files later wants to write to one of these blocks, it instead writes to a new block and then updates its pointer to this new block while the old file keeps pointing to the original block (this is where the term copy-on-write comes from).

So it isn't like traditional incremental backups where you have to take the original full backup and then apply all the deltas to get the current state of the file. All of the data for all the snapshots is there in blocks and the blocks of a single file can be (and are) distributed across multiple disks - whether a block is used by multiple files or not is irrelevant to ZFS.

Re:Delta-based backups?

[Jay L]

Well, I'm familiar with the concept of RAID, but I've never sat down and thought through the exact striping scheme, so thanks for the intro. (I usually end up going straight to RAID-10.)

I'm still confused on the original point, though. I understand that ZFS doesn't use deltas, exactly, but it still uses their moral equivalent; it saves space by storing a pointer to the original block. So I feel like you run into the same problem.

Let's look at a degenerate example: /source is a hard drive that can store exactly five blocks of one character each. I store "ABCDE". I back it up to a ginormous ZFS volume, /backup-log, which has one physical volume, /backup1-phy, that holds ten one-character blocks. Initially, /backup1-phy contains "ABCDE-----" (where "-" represents an empty block). /backup-log also shows "ABCDE-----" in its "current view" (whatever ZFS calls that non-snapshotted real-time view).

Now I take a ZFS snapshot on /backup-log, delete /source/E, and create /source/F. /source now contains "ABCDF". Next time I back up, /backup-log looks like "ABCDF-----"; because the snapshot still uses "E", /backup1-phy contains "ABCDEF----".

I keep going down this road, until /source contains "FGHIJ". /backup1-phy now contains "ABCDEFGHIJ" among various snapshots; /backup-log just shows "FGHIJ".

Oh noez!! /backup1-phy is full. No problem; I'll just add /backup2-phy to the /backup-log volume. Now, when I take a snapshot on /backup-log, delete /source1/J and add /source1/K, I should be fine.

Except, and this is the part I don't get: Either (a) there is going to be a snapshot on /backup-log that depends on BOTH /backup1-phy and /backup2-phy, or (b) everything on /backup1-phy needs to be copied to /backup2-phy.

Maybe the answer is (a), and maybe that's fine, because underneath the snapshot layer, we've still got a parity layer that can deal with one of /backup1-phy or /backup2-phy failing. I can't really articulate *why* that doesn't feel right; there's just something about it that screams "wrong" to me, or at least it screams "less reliable than partitioning your data so any given file depends on only one volume".

I am not sure where you are failing to understand

[Jane Q. Public]

but you are. And no, I am not saying that Apple should include the filesystems themselves (though it would not bother me if they did).

First, if you have to INSTALL SOMETHING (even a small something) other than the filesystem itself, BEFORE other filesystems can be used, then by definition it is not "out of the box"! Whether you regard that as a small point or not, it is still a point, and it makes a difference to a lot of people.

Second, according to TFA, ZFS will be provided for the server product, not for plain off-the-shelf, out-of-the-box Mac OS X. And that was part of my point.

Third, MacPorts (like the other examples you gave) is yet another outside-party add-on; it is NOT an "out-of-the-box" feature of OS X!

And fourth, I have an excellent grasp of what "pluggable" means. That has no bearing whatever on whether it is supported out-of-the-box, versus a self-compiled add-on or the like!!!

Maybe this is where you have been misunderstanding: you have been saying that OS X has native support for pluggable filesystems. What I have been saying is "NO, it does not... until you install some add-on software". Sure, once you install one or more of those add-ons, then it does. But saying that is "native, out-of-the-box" support for pluggable filesystems is like saying that Windows has "native, out-of-the-box support for solving mathematical integrals". It simply doesn't. You can get "add-ons" -- additional software -- that does. Even for free. But that is NOT the same as "native, out-of-the-box support."

If that does not clear things up for you, then I doubt anything will. But I know that nobody where I work would have any trouble understanding this.

Re:"All features on this page are subject to chang

[Anonymous Coward]

The world has been waiting for WinFS since Windows NT 4.0 was supposed to be replaced by an operating system from Microsoft with a new relational file system in NT 5.0.

WinFS is far too little and way too late.

Microsoft would be better off bundling production tested ZFS, rather than rolling their own non-production tested file system and releasing an untested system a decade too late.

Re:I am not sure where you are failing to understa

[Anonymous Coward]

First, if you have to INSTALL SOMETHING (even a small something) other than the filesystem itself, BEFORE other filesystems can be used, then by definition it is not "out of the box"!

Sorry, but you're the one who isn't understanding -- you don't have to do any such thing! Apple's own ZFS is an example of that. The developer samples they provide are examples of that. Inactive open source projects like ext2fsx are examples of that. The various commercial (e.g. Paragon NTFS) and in-house filesystem extensions in use in obscure places (e.g. VirtualPC, Parallels, Symantec's filters, etc) are examples of that.

It's just that not many non-commercial developers are providing filesystem modules for OS X. Filesystem development is some of the most demanding work there is. That's why FUSE is popular: the filesystems are implemented as userland applications, where the demands of the programming environment are much less intensive.

Everything that uses FUSE (Linux, NetBSD's PUFFS, MacFUSE for OS X, etc) takes the form of installing a framework module in the kernel, which in turn uses the FUSE interface for the userland filesystems. This has absolutely nothing to do with out-of-the-box support for anything; it's just an abstraction that's made it easy for people experimenting with filesystems across several OSes, thus more filesystems are available with it. If you don't want to use that abstraction, that's fine, but it has nothing to do with an operating system's support for pluggable filesystems (other than showing it exists in the first place).

Ignoring the first link I gave you, which details the level of support available in OS X according to Apple itself, and instead trying to play semantic games using a single sentence from the MacFUSE homepage in order to justify the incorrect position that OS X does not support pluggable filesystems is the height of arrogance.

Second, according to TFA, ZFS will be provided for the server product, not for plain off-the-shelf, out-of-the-box Mac OS X. And that was part of my point.

ZFS is provided by Apple for OS X Leopard right now; it's just not officially supported for production use because it's a work-in-progress and still contains bugs. It will continue to be available for Leopard, and will therefore also be available for the non-server version of Snow Leopard.

Apple may, of course, choose to not officially support it on the non-server version, much like they did for both the journaled and case-sensitive versions of HFS+ in the beginning. If that's the case, then it will likely be supported at some point after Snow Leopard.

But what exactly is your point over that? And what on earth does it have to do with pluggable filesystem support? It's just a question of what Apple chooses to provide itself, which you already said was not an issue.

Third, MacPorts (like the other examples you gave) is yet another outside-party add-on; it is NOT an "out-of-the-box" feature of OS X!

MacPorts is a package management system and repository for OS X. Of course it's an add-on, just like all the package management systems for every other OS out there. I mentioned it because it's a convenient method of obtaining software and may be familiar to you if you like other package managers. But what does that have to do with pluggable filesystem support?

And fourth, I have an excellent grasp of what "pluggable" means. That has no bearing whatever on whether it is supported out-of-the-box, versus a self-compiled add-on or the like!!!

I remind you of your assertion in your original post:

If Apple really wants to start calling OS X a "modern" operating system, they are going to have to start supporting pluggable filesystems.

You don't get to change the argument now. You're absolutely ri

Re:"All features on this page are subject to chang

[zonker]

You forgot the most important feature. You know, the one about boiling the oceans of the world...

No, I am understanding just fine.

[Jane Q. Public]

First, the ARTICLE we were supposed to be talking about mentioned ZFS for their future server product. It was not mentioned that it would work as-is in already-distributed OS X. If it does, then great! But you (and some references I have seen) mention that it has bugs. So... it is not a supported product yet. That was part of my point. Because it is not yet supported, it is not yet an example.

However, I went back and looked at your first post to see what you meant. And indeed, there was a link there that I missed the first time. I did not "ignore" it, I simply did not see it the first time around. And yes, it does say that 10.4.x and later support VFS plugins. My bad on that one. But I did not see that ANYWHERE else, and the examples you were giving were NOT examples of that: they were examples of plugins that worked through a third party add-on. Thus that misunderstanding.

So OS X does support pluggable filesystems... but unless I missed something else too, I still have not seen any examples of a filesystem that works directly as a VFS plugin without using OTHER software or drivers as an intermediary. This is where we seem to be having trouble communicating. MacPorts, for example, is an easy to get add-on for OS X. But it is NOT a "feature" of out-of-the-box OS X. (Apologies for repeating "out-of-the-box" so many times but apparently you have been having trouble understanding that this is what I have been referring to all along, as I explained some time back.)

As far as I have been able to tell with brief looks, the filesystem examples I have seen all work through some other add-on that has to be installed first. (Aside from ZFS, which as mentioned does not count). And that was the point I have been trying to make. Show me a filesystem that is ready to go, right now, without having to compile anything, and without having to install any other software. THAT is what "out of the box" means! I don't care where the filesystem itself comes from, but in order to qualify it must not use third-party tools or software to install. Show me a nice little package that will install on OS X directly as a filesystem, and that is relatively free of bugs, and does not require compiling or any other software to run. I.e., it installs "out of the box" on "out of the box" OS X.

I brought up kernel extensions that are separate from the filesystems themselves for precisely this reason, which you seem to keep evading: THAT IS NOT "OUT OF THE BOX"! That is an add-on. It doesn't matter if it comes from Apple, or Google, or Paul Reiser. You have to go get it and ADD IT ON. I do not understand why you have had such trouble with this simple concept. You may not care whether you have to compile it first or not, but whether YOU find it easy is NOT the point! A lot of people do care, and won't go to the trouble.

You are a bit late quoting about "out-or-the-box" and saying that I "changed my argument". I did nothing of the sort. Some posts back I clarified it for you, by stating that I felt that the context made it quite clear that I was talking about "out of the box" functionality... because it seemed clear to me at the time that you did not understand what I meant. But I do not understand, now that I have explained that many times now, why you have kept sidestepping that issue.

And again, I do not recall even one example from this discussion that was, in fact, "out-of-the-box" OS X. All of the examples you gave, as best I can tell even now, used at least some kind of add-on intermediary software before they could be made to work on OS X (other than the filesystems themselves). There may be some FINISHED, working filesystems that you can obtain and plug straight in to an OS X machine without using some kind of other extension first, but I had not seen any examples of such, including yours.

ZFS and the developer examples, once again, are NOT examples of what I was talking about! They are works-in-progress, NOT finished, out-of-the-box features of (or plugins for) OS X!

Re:No, I am understanding just fine.

[gutter]

It is pretty hard to tell from your tirades whether you are talking about the ability to support pluggable filesystems, or the availability of those pluggable filesystems. You seem to be conflating the two. You start by complaining that OS X lacks the ability to support pluggable systems, but the first link from the AC's post proves you wrong:

http://developer.apple.com/qa/qa2001/qa1242.html

In fact, every filesystem OS X supports is written using this mechanism, out of the box:

[gutro:~/] gutter% ls -1 /System/Library/Filesystems/
AppleShare
URLMount
afpfs.fs
cd9660.fs
cddafs.fs
ftp.fs
hfs.fs
msdos.fs
nfs.fs
ntfs.fs
smbfs.fs
udf.fs
ufs.fs
webdav.fs
zfs.fs

Your most recent tirade seems to be a complaint about the lack of available filesystems, which I guess is a reasonable complaint, but that's not what you orignally asked for. Then you asked for a simple package you could download and install, and again, the original reply contained one (MacFUSE). Granted, that's a poor example, because it hides OS X's native pluggable FS support behind the FUSE pluggable FS support, but that doesn't mean that the AC was wrong. You can go and download the MacFUSE package, and the sshfs package, install them using the standard installer, and begin using a filesystem that works over SSH, no compiling necessary. (Incidentally, that one is super handy).

In short, the original reply by the AC was 100% correct, and you were 100% wrong, (and seemingly unable to comprehend his reasonable explanations) and somehow by sheer bluster, you seem to have convinced everyone of the opposite.

Re:No, I am understanding just fine.

[Anonymous Coward]

First, the ARTICLE we were supposed to be talking about mentioned ZFS for their future server product. It was not mentioned that it would work as-is in already-distributed OS X. If it does, then great! But you (and some references I have seen) mention that it has bugs. So... it is not a supported product yet. That was part of my point. Because it is not yet supported, it is not yet an example.

The fact that it works at all makes it a perfectly good example of OS X's support for pluggable filesystems. It's not a good example of a finished product, no, but that's not what your original post was about. The issue was whether OS X supported pluggable filesystems, not whether people have created complete, polished filesystem plugins for OS X.

However, I went back and looked at your first post to see what you meant. And indeed, there was a link there that I missed the first time. I did not "ignore" it, I simply did not see it the first time around. And yes, it does say that 10.4.x and later support VFS plugins. My bad on that one. But I did not see that ANYWHERE else, and the examples you were giving were NOT examples of that: they were examples of plugins that worked through a third party add-on. Thus that misunderstanding.

Yes, MacFUSE was a bad choice for a first example on my part.

MacPorts, for example, is an easy to get add-on for OS X. But it is NOT a "feature" of out-of-the-box OS X.

For clarity's sake, note that MacPorts itself is essentially a collection of open source software packaged specifically for OS X. In the context of filesystems, it's simply an alternate way to get MacFUSE and a few filesystems that use FUSE, with the MacPorts people shouldering the burden of making sure they install properly on OS X without hassle. MacPorts doesn't provide any new filesystem support itself, and makes a lot of other software available.

As far as I have been able to tell with brief looks, the filesystem examples I have seen all work through some other add-on that has to be installed first. (Aside from ZFS, which as mentioned does not count). And that was the point I have been trying to make.

But the only relevance here would be to argue that the OS X kernel has no support for pluggable filesystems, and that a third party had to add that support through some other means. As I've been trying to establish for several posts, OS X does indeed have that support. The prerequisites of some projects are therefore beside the point.

I brought up kernel extensions that are separate from the filesystems themselves for precisely this reason, which you seem to keep evading: THAT IS NOT "OUT OF THE BOX"! That is an add-on. It doesn't matter if it comes from Apple, or Google, or Paul Reiser. You have to go get it and ADD IT ON. I do not understand why you have had such trouble with this simple concept. You may not care whether you have to compile it first or not, but whether YOU find it easy is NOT the point! A lot of people do care, and won't go to the trouble.

In the context of the FUSE filesystems, MacFUSE is simply a prerequisite, which is fairly common for software. Being an add-on has nothing to do with compiling; as I pointed out earlier, getting the popular NTFS-3g working merely takes 2 downloads. No compiling involved.

FUSE is popular simply because it's easier for developers than doing kernel extensions.

You are a bit late quoting about "out-or-the-box" and saying that I "changed my argument". I did nothing of the sort. Some posts back I clarified it for you, by stating that I felt that the context made it quite clear that I was talking about "out of the box" functionality... because it seemed clear to me at the time that you did not understand what I meant. But I do not understand, now that I have explained that many times now, why you have kept sidestepping that issue.

I sidestep it because it's a specious argument. Your original statement was that Apple n

Re:No, I am understanding just fine.

[Jane Q. Public]

Well, if what you say in the last few paragraphs is correct, then I was simply wrong, in the case of at least one good example. I can admit that, when someone shows me that is indeed the case.

But I would still like to state, for the (how-manyeth?) time, that we are still not communicating about the rest of this.

While my first post did indeed state "pluggable filesystems", I have explained -- many times now -- that what I MEANT was "out of the box" functionality, WITHOUT third-party add-ons or separately compiled kernel extensions. I even explained why that is important to some people. So, I know what MacPorts is... I use it myself. But because of the restriction I mentioned, something that needs MacPorts disqualifies itself.

I did NOT state that what third parties do equates to what Mac does itself. I claimed the opposite! My assertion was (for this argument) that the need for third-party tools disqualified a filesystem from my (so far practically nonexistant) list. I have stated that so many times in different ways now that I despair of you ever understanding the point. Others who have read this did not have that trouble, so I do not know where the misunderstanding could lie.

And finally, I have also stated that ease of use for an experienced user is not the real issue. The issue is whether mom-and-pop will bother to do all that just to get a filesystem running. And the answer, in the case of MOST end-users, is no.

For someone who keeps claiming that I am ignoring what the other is saying, you have been doing a lot of ignoring.

In any case, I am completely done with this discussion. I am now convinced that there ARE "ready to go" filesystems out there... at least one anyway. But as for the rest of this "discussion", absolutely no progress has been made for at least three go-rounds now.

Re:No, I am understanding just fine.

[Jane Q. Public]

I am sorry you are having so much trouble understanding what I have been saying. As I stated elsewhere, other people I know of who have read this thread did not have such problems (other than the main other party to this discussion, of course).

Your list is nice, but let me ask you just one thing: why in the world would I bring up pluggable filesystems at all, if I were only interested in filesystems that ALREADY come with the OS?

That does not make any kind of sense at all to me.

Obviously I meant filesystems OTHER THAN what were already included. So... where are all the OTHER filesystems that use this SAME, cool native plug-in system? Anybody? Hello? There must be someone there to speak up! Going once... going twice... Hmmm. If there aren't any, the fact that it is supported is moot.

I have also stated several times (and EXPLAINED WHY already more than once) that I was not interested in filesystems that used a third-party intermediary like MacFUSE.

Re:No, I am understanding just fine.

[Anonymous Coward]

While my first post did indeed state "pluggable filesystems", I have explained -- many times now -- that what I MEANT was "out of the box" functionality, WITHOUT third-party add-ons or separately compiled kernel extensions. That's what I meant about changing the argument. It went from "Apple needs to support pluggable filesystems in OS X" to "third parties need to supply native filesystem extensions for OS X". There's nothing wrong with that argument, but it's completely different from what was in your first post. The first is about what Apple does in OS X; the second is about what third parties do for OS X.

I did NOT state that what third parties do equates to what Mac does itself. I claimed the opposite! From your previous post (emphasis added):

So yes, according to your first link, OS X does "support" pluggable filesystems. But until those filesystems are readily available in nice, neat little packages that are READY to plug in, without multiple intermediate steps, then it is still not an "out of the box" feature of OS X. The quotes around the word "support" indicate you're qualifying that somehow; based on the surrounding context it appears you're implying Apple/OS X has fake or cosmetic support because of what third parties are (not) doing.

The second sentence is less vague: it literally says that the format of third-party filesystems determines the existence of a feature in OS X itself.

Perhaps that isn't what you meant to say, but it's certainly not ambiguous.

And finally, I have also stated that ease of use for an experienced user is not the real issue. The issue is whether mom-and-pop will bother to do all that just to get a filesystem running. And the answer, in the case of MOST end-users, is no. I don't dismiss the ease-of-use argument, but I assert that mom and pop won't be looking for filesystems in the first place. Only experienced users actually understand what filesystems are; for most people the computer just stores stuff, and how it does that is unimportant.

Having to install the developer tools and compile something, or track down 5 different dependencies before you can get something working, are certainly barriers I wouldn't expect most people to bother with. Those barriers don't exist for the most common MacFUSE stuff though, and your distinction of one download vs two is an artificial barrier that doesn't exist in practice. If someone wants to get read/write NTFS support in OS X without purchasing anything, finding and installing the two necessary packages is trivial.

Of course, if someone wants to take MacFUSE off the list of things they personally consider usable, that's their prerogative. It's just more likely to be a decision based on philosophical grounds rather than practical concerns, as very little effort is involved in using it.

Re:No, I am understanding just fine.

[gutter]

Here in the real world, "unsupported" means "it can't be done", not "nobody has done it". So, when you said it was unsupported, you were just wrong.

However, just for fun, here is an example of an available 3rd party filesystem using the VFS support: Ext2 for OS X:

http://sourceforge.net/projects/ext2fsx/

It is of course true that there aren't many, but I've listed two now (again, just because you aren't interested in one of them, doesn't mean it doesn't exist). There's probably a good reason for that - the number of people needing to use a FS other than the included ones on OS X is tiny. Of course, now you are probably going to complain that ext2 doesn't interest you either, and that it doesn't support your favorite filesystem. That may be a reasonable complaint, but it's not what you asked for.

Why Replace Before Failure?

[Slashdot Parent]

personally, I think SMART was developed by the drive companies to sell more drives. Frequently, admins (myself included) will replace a drive that they have a bad feeling about. What's the use in replacing a drive before it fails?

When SMART starts whining about a drive, I order a replacement. But I don't replace until the drive fails.

Memory caching

[ttfkam]

Is not a bad thing as long as it doesn't aggressively claim the memory. For example in Linux, the OS will try to use all available memory. Some of it will be by the kernel itself, a large part by applications, but a great deal of the rest as a memory cache of your filesystem (hard drive) accesses. However, if memory becomes tight, the OS will cache less of the filesystem to allow the applications more breathing room. This makes the hard drive work harder and, by result, makes your system less responsive.

The solution is not to get a filesystem that uses less memory. The solution is to get more RAM; it will probably increase your system performance more than a faster hard drive or CPU would.

ZFS isn't into bondage and humiliation

[Anonymous Coward]

We swapped text messages once. ZFS isn't into shitting all over anyone. Just not a thing ZFS would even consider, frankly. Sure, maybe a little light bondage like everyone else. Safe word is "fsck".

LMAO

[Anonymous Coward]

This is so hilarious. I'm reading through this thread about a week later, and it's hard not to bust up laughing.

what I MEANT was "out of the box" functionality, WITHOUT third-party add-ons or separately compiled kernel extensions.

and then, later...

Your list is nice, but let me ask you just one thing: why in the world would I bring up pluggable filesystems at all, if I were only interested in filesystems that ALREADY come with the OS?

Wow. Just wow. Do you really not understand the massive contradiction in the above words? That you have repeated multiple times within this thread? Your ignorance is only surpassed by your absolute subbornness.

Tell me, how exactly can a "pluggable filesystem" can have the following properties:

• Out of the box functionality
• No third-party add-ons
• Does not ALREADY come with the OS

Do you see the contradiction yet? How does something not come with the OS, but at the same time exist "out of the box" and not be from a third party? Hello?? McFly?

That does not make any kind of sense at all to me.

Well, at least you got one thing right. Look, if you want to use a filesystem that doesn't come with the OS, you're going to have to install extra software or files: a third-party add-on, if you will. There is no way to avoid that. And what do you care how it interfaces with the kernel on a low level? As long as it works well, who friggin' cares at all?

Better stick to cooking and sewing, sweetie. Logic is clearly not your forte.