Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Apple Looking at ZFS For Mac OS X

Posted by Hemos on Mon May 01, 2006 07:59 AM
from the only-the-shadow-knows dept.
Udo Schmitz writes "Apples Filesystem Development Manager, Chris Emura, is looking into porting Sun Microsystems' file system ZFS to OS X. At least this is what Sun's Eric Kustarz states on the ZFS mailing list. Is this a glimpse of hope for all those of us who think HFS+ isn't up to par for a 21st century OS? Next thing you know and they'll rewrite the Finder ..."
+ -
story

Related Stories

[+] Slashback: Moon Footage, KillerNic, ZFS Leopard 207 comments
Slashback tonight brings some clarifications and updates to previous Slashdot stories including: some direct answers to Slashdot questions on the KillerNIC, recap in stolen laptop identity theft problems, a victory for one PayPal user, missing moon footage surfaces, Dell laptops unwelcome on Quantas flights, and more ZFS news from the Leopard front Read on for details.
[+] Apple: ZFS Shows Up in New Leopard Build 351 comments
Udo Schmitz writes "As a follow-up to rumours from May this year, World of Apple has a screenshot showing Sun's Zettabyte File System in "the most recent Build of Mac OS X 10.5 Leopard". Though I still wonder: If it is not meant to replace HFS+, could there be any other reasons to support ZFS?"
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Have a look at wikipedia's Comparison of file systems [wikipedia.org] page to see the difference between ZFS & HFS+.

    The main advantage for HFS+ users (I mean who's really going to need a 16,000,000 Gigabyte file) would be the introduction of journalling beyond metadata (and even this is unlikely to be useful to most people).
    • by lokedhs (672255) on Monday May 01 2006, @08:22AM (#15236327)
      I think the major advantage is the fast snapshotting and cloning. It uses copy-on-write so that it doesn't take more space than what you actually change.

      Imagine being able to take really fast working copies of whatever you're doing and be able to simple use the old versions by cd'ing to the old clone.

      That's certainly what I would use ZFS for. The rest of the stuff, pooling and mirroring and stuff is less interesting in my laptop. :-)

      • Also -- hard links. One would be hard pressed to find a filesystem with poorer hard link support than HFS+, except those that don't support links at all.
      • As a part time graphics guy, this feature would make life much better.... I periodically have to save very large files after having made the smallest of changes... a typo for example... and yet saving the document takes as long as if I had made a full copy of the file.

        I would love for the FS to do snapshot saves with incrementals and checkpoints and rollback, instead of having each application do it. This provides unlimited undos potential with actual stored versions... a true 'history' of the file, availab
      • The rest of the stuff, pooling and mirroring and stuff is less interesting in my laptop. :-)

        Quite to the contrary! The most unreliable element in your laptop is your drive. It will fail at some point, have no doubts about it. ZFS will detect silent failures through its checksumming.

        ZFS also makes it possible to do super-fast backups to external disk. Combine that with snapshots and you have the kind of data security enterprises pay a whole lot of money for. Here's how it works:

        1. Find an external disk th
        • I think it's a quantum leap. Not because of the snapshotting or error checking, but the thing that really makes ZFS a completely different beast is that it is (to my knowledge) the first file system (or should I say "storage technology"?) that actually joins two traditionally separate concepts: file systems and volume management.

          Thanks to this, a lot of interesting stuff becomes possible, such as the fast file system creation which is demonstrated in this very cool demo [opensolaris.org].

          If you don't consider ZFS a qua

          • by TheRaven64 (641858) on Monday May 01 2006, @12:36PM (#15238554) Homepage Journal
            but the thing that really makes ZFS a completely different beast is that it is (to my knowledge) the first file system (or should I say "storage technology"?) that actually joins two traditionally separate concepts: file systems and volume management.

            I can tell you grew up in the UNIX world. Everything I read about ZFS reminds me very much of VMS. Twenty years ago. If you read the UNIX Hater Handbook (published 12 years ago), then you will find a very nice rant about how the UNIX concept of partitions is a huge step back from what VMS offered. Now, over a decade later, it seems someone has listened.

            • I agree that there was a lot in VMS that the world has "lost". I think that modern UNIX implementations should look at what VMS had, to reuse some of the good ideas that we still have not replicated. My favorite is the security system -- various small capabilities that each user (or program) could be granted. And the super-user only had one capability by default: the ability to grant privileges. I also appreciated the automated versioning, with the ability to pull up a previous version from the filesystem without having to use any special programs.

              And yes, I know that Windows NT is sort of descended from VMS. But I've not seen many of the concepts make it up to userland cleanly implemented.

              And I'm also aware that VMS is still around. It may not be on life-support yet, but it's clearly in the nursing home already.
        • I've made a few "what about UFS?" comments in this story, but I hope I don't come across as some weird filesystem fanboy. It's just that I can't figure out why this announcement is so exciting. ZFS is cool, sure, but I see it as an incremental improvement to widely used Unix filesystems rather than a quantum leap.

          I think part of what makes this story so interesting is that despite the past few years' developments, most of us still expect Apple to act as it used to with regard to adopting new technology. In
    • I mean who's really going to need a 16,000,000 Gigabyte file
      A post from slashdot in the year 2030:
      Sure, it may seem to be overkill but remember when Whiney Mac Fanboy said "16,000,000GB should be enough for anyone"?
    • Journaling beyond metadata? Wouldn't that aid file recovery if the writing software screws up a write?

      If ZFS is included, it may be a sign that Apple is considering a bigger plunge into the enterprise markets because that seems to be where ZFS can shine. They are big in the storage markets with XServe RAID enclosures, both drive capacities and even orders seem to be going up.
    • I mean who's really going to need a 16,000,000 Gigabyte file

      Actually, I keep an archive of all Slashdot dupes...

    • Apart from those pluses mentioned by lokedhs [slashdot.org] (snapshotting is no trivial feature to have, if you're running databases, for example, or want admin abilities [sun.com] like rollback [sun.com]) - What ZFS offers that no other Linux filesystem offers, let alone HFS+, is end-to-end data integrity [sun.com] and self-healing [opensolaris.org]. That's why I picked Solaris 10 for a high-integrity database app recently. Nobody else could offer the integrity guarantees (apart from some SAN vendors perhaps).
      • by captnitro (160231) on Monday May 01 2006, @08:39AM (#15236425)
        Since OS X.3, I believe the kernel has defragmented files under 20 MB on the fly [macslash.org].
      • by clifyt (11768) <sonikmatter.gmail@com> on Monday May 01 2006, @09:38AM (#15236855) Homepage
        "HFS+ is subject to fragmentation (but Apple, like MS, provides no tools to help you deal with it)"

        Talking in depth to one of the original OS X engineers (there were 4 or 5 depending if you count Jobs as one of them -- they all claimed Jobs gave as much input to the original porting of Next to the new OSX as anyone else did), his claim was that fragmentation isn't a problem.

        Apple specifically doesn't offer tools because it defrags files as it makes sense to the operating system -- and generally doesn't defrag at all except for tiny files because modern drive and multiple independent read / write heads on drives today make a bit of entropy a good thing. If I remember later conversations correctly, he also mentioned that Apple had several graphic based disc tools that could do the same things that the OS does on an individual file basis, but didn't see the point in releasing them because this was something that should be left up to the OS and not up to the user. I argued that the user should have control and he countered with the fact that unless you had intimate knowledge about the drives physical features as well as the OSs specific needs, you are more likely going to slow things down in your quest to align the pretty colors together on your defrag program.

        What was interesting was that he also recommended that you never fill a drive past 60 or 70 %. The claim was that having a huge chunk of empty space allowed the OS to do its thing without having to resort to smoke and mirrors.

        Note -- defragging is an IMPORTANT part to my audience. I deal with musicians and engineers working on digital audio workstations. I remember using specific defraggers that were used solely for our industry (i.e., would write audio files to areas of the disc that were claimed to be the fastest read / write). I followed this skeptically -- until my contact forwarded me to a counterpart of his at Microsoft that essentially said the same thing -- in a MODERN OS using modern hardware, this does more harm than good.

        Do I believe that a user couldn't get more optimized use out of defragging their own drives? I don't really know...but I'm going to trust these guys. Do your own research though. For all I know, I was told a line of BS that is intended to keep people like me from poking around under 'modern os`s' :-)
        • by Kjella (173770) on Monday May 01 2006, @04:07PM (#15240452) Homepage
          Look up any decent hard disk review site and compare sequential read vs random reads, and you'll see that it suffers quite badly. As for the operating system handling that, I don't know about OS X but Windows certainly doesn't. The "never fill it past 60 or 70%" is simply because than the OS can pick large open chunks, avoiding fragmentation but it does nothing to fix fragmentation. Once your drive has been close to 100%, the last files will be in a zillion fragments all over the disk. They will sit around like little road bumps making sure all other files will be fragmented too.

          That said, most desktop users will not notice a big difference between a fragmented, quick-defragment (defrag files, but don't consolidate free space) and full defragmented disk. A typical modern HDD has a 35-40MB/s minimum transfer rate. DV, probably the most resource intensive any normal person bothers with has a measly 25Mb/s = 3,2MB/s. Unless you're suffering from really horrible fragmentation, that should be no problem. Same goes for analog capture with hardware/on-the-fly compression. Yes, there are fringe areas like raw analog video or scientific data but audio capture isn't part of it anymore. And if you're that specific, using a separate tool isn't that big a deal. Servers OTOH might be something, but I imagine most of that is handled by other parts than the OS disk I/O.
            • by clifyt (11768) <sonikmatter.gmail@com> on Monday May 01 2006, @11:23AM (#15237749) Homepage
              This was actually addressed.

              If you keep around 70% of your drive free, the machine will be able to make large enough chunks that given a combinations of other factors it was meaningless.

              It was said with multiple independent read write heads, you can actually fill the buffer faster by spreading the load out in noncontiguous sections...and even if it did need to read sequential sections from the same head in different areas, both that the drive can read files nonsequentially and load these chunks into the cache while the other read head is catching up -- and that it takes less than a ms to jump from one sector to another these days.

              The clue that was beaten into me was to think of this as sorta a spanned raid within a single drive and that's entirely how these work these days (and then told its entirely not like a raid so I shouldn't use that metaphor lest some nerd that thinks with his head instead of his gut tells me that I'm wrong -- ok I made up the last part, but its essentially what I was told).

              But all in all, as other have mentioned, HSF+ likes to defrag on the fly non-contiguous chunks of less than 20 megs (and it will also do this in the background after the CPU is more free after seeing these) -- and given that the average cache on a drive is around 16 Megs, even when this inevitably doubles in the next year or two, the logic remains that this is still good enough.

              But you are entirely right -- if drives didn't employ caching and multiple independent read write heads (i.e., early multiple platter systems required that the read/write heads all be driven by the same motor and thus killing any attainable speeds).

              Blah blah blah...its all pseudoscience and phrenology to me. I'm just mouthing everything that was sent to me without understanding a word of it. I'm a musician (and technically a pseudoscientist by trade) so making up words and using them incorrectly by mirroring others comes naturally and might even make sense to those that don't know any better :-)
  • But why just ZFS? Why not add JFS or XFS as well? Hell, why not add in ext3 while they're at it? Speaking of which, does anyone have Mac OS X running with a native non-HFS, non-UFS filesystem?
    • I wonder the same thing with windows. There are only 2 file systems. FAT32 and NTFS. I don't think this is a good idea. There is no one filesystem that works best in all cases. That's what's nice about Linux. There's like 10 different file systems to choose from. Maybe most people leave it at whatever the default is. But that doesn't matter. For those who care to research enough, and find out which filesystem is the best for their system, they will be able tos see the advantages. The other nice
      • Maybe most people leave it at whatever the default is. But that doesn't matter.

        That's one of the differences between being a company and being an open source project. For a company, it does matter; supporting every filesystem under the sun is a detriment, not a benefit, because there are real incremental costs for each additional one you add.
    • "But why just ZFS? Why not add JFS or XFS as well? Hell, why not add in ext3 while they're at it?"

      Supporting lots of filesystems is hard. Mistakes are difficult to track down and harshly punished, licenses and API's generally aren't amenable to straight ports, and it's a lot of work for what's typically a fairly small ROI. Also, porting one filesystem doesn't generally make porting another significantly easier. You might as well ask:

      "But why just a skyscraper? Why not add a warehouse or a subterranean bu

  • by LakeSolon (699033) on Monday May 01 2006, @08:16AM (#15236297) Homepage
    A story that consists of a link to wikipedia and a mailing list posting about an OS possibly (maybe, potentially) switching filesystems.

    Beats the heck out of story about a blog posting that's just a regurgitation of an MSNBC article that doesn't know what the frack it's talking about.
  • by squiggleslash (241428) on Monday May 01 2006, @08:18AM (#15236306) Homepage Journal
    Here's a listing of the file systems currently supported on OS X Panther (it may be more for Tiger, I don't know):
    $ ls -l /System/Library/Filesystems/
    total 0
    drwxr-xr-x 8 root wheel 272 14 Mar 12:46 AppleShare
    drwxr-xr-x 7 root wheel 238 12 Apr 2005 URLMount
    drwxr-xr-x 6 root wheel 204 14 Mar 12:47 cd9660.fs
    drwxr-xr-x 3 root wheel 102 22 Dec 2004 cddafs.fs
    drwxr-xr-x 4 root wheel 136 14 Mar 12:48 ftp.fs
    drwxr-xr-x 5 root wheel 170 14 Mar 12:47 hfs.fs
    drwxr-xr-x 4 root wheel 136 14 Mar 12:47 msdos.fs
    drwxr-xr-x 4 root wheel 136 14 Mar 12:47 ntfs.fs
    drwxr-xr-x 4 root wheel 136 14 Mar 12:47 udf.fs
    drwxr-xr-x 4 root wheel 136 14 Mar 12:46 ufs.fs
    $
    HFS and UFS are the official choices of file system for installing your bootable OS X or Darwin system. The rest are either network based file systems or are specific choices for interoperability with other operating systems.

    There are many reasons why Apple might be looking at ZFS. Only one is that Apple intends to actually make Mac OS X use it as a home filesystem.

    Now, here's a reason the write-up author didn't think of: Apple is rumoured to be working on a virtualization layer for OS X, with the intent being that OS X will run in parallel with multiple operating systems. Even if that rumour is false, it's clear that with BootCamp, Apple is taking the idea of Macs running multiple operating systems (albeit not at the same time...) seriously. Solaris and GNU/Linux are the two most popular Intel platforms save for Mac OS X and Windows.

    Isn't it more likely that Apple wants Mac OS X its multi-OS Macs to "just work" with the other operating systems, able to achieve a high degree of interoperability without forcing the other platforms to support HFS+?

    I'm not saying a move to ZFS would be a bad thing, though it doesn't, so far as I can see, support arbitrary metadata so it'd be as practical as UFS in its current form, which is barely used by Mac users. I just think a port of the main Solaris file systems is, in practice, something Apple would be doing anyway, as part of the Intel OS-agnostic direction they're going in.

    • by Anonymous Coward on Monday May 01 2006, @08:23AM (#15236340)
      ZFS actually is a ver good file system.

      Here is the ars technica low-down on what ZFS does differently and why that's such a good thing.

      arstechnica.com/news.ars/post/20051117-5595.html [arstechnica.com]

      • It's probably very good in the performance arena, but for some reason, it still appears to live in the 1970s in terms of what it stores - ie named flat files.

        At the very least, I'd expect any file system Apple would consider suitable for switching to to support arbitrary metadata. A server based system like Solaris may not need it so much, but a desktop system that associates icons, file types, and miscellaneous information useful in searching, really should use a file system that supports arbitrary metad

    • Solaris and GNU/Linux are the two most popular Intel platforms save for Mac OS X and Windows.

      What about the various BSDs?
        • Ugh... I tried reposting listing anonymously for a higher rating, but I forgot that posting as AC removes karma and logged in bonus... so here I go being TREBLY redundant.

          For the record, if I had mod points I would have modded GP up as "Informative"

          Last login: Thu Apr 20 18:20:18 on ttyp1
          Welcome to Darwin!
          [athena:~] aibrahim% ls -l /System/Library/Filesystems/
          total 8
          drwxr-xr-x 9 root wheel 306 Apr 4 11:14 AppleShare
          drwxr-xr-x 7 root wheel 238 Apr 2 2005 URLMount
          lrwxr-xr-x 1 root wheel 49 Nov
  • by rpk (9273) on Monday May 01 2006, @08:22AM (#15236328)
    There are probably two things that Apple would be looking for in ZFS: a shiny feature they can point to for their enterprise and video production markets, and for the consumer market, the promise of a simple, reliable way to back up and grow the storage of a Mac without have to worry about mounting/copying/moving volumes, managing backups, etc.
      • Re:one word (Score:2, Interesting)

        Yeah, it's pretty clear that for heavy-duty use, HFS+ is not really the way to go. With ZFS, Apple can build on what Sun has done, while at the same time they don't have to touch HFS+ at all, or fix all the it-doesn't-quite-work-like-HFS+ issues that UFS has. It makes a lot more sense for them to get ZFS to "just work" than to put that work into the existing UFS implementation.
  • Dont most of us now use UFS?

    And from the view point of a average user, he wont see a difference regardless of what FS hes using..
    • I don't think very many people at all use UFS on OS X. UFS is case sensitive. HFS+ can be case-insensitive but case preserving or case sensitive depending on the options specified to create the volume. UFS doesn't have journaling support, HFS+ does. UFS stores POSIX metadata. HFS+ stores arbitrary metadata. UFS files have single fork. HFS+ files have a data fork and an arbitrary number of other forks. UFS stores the meta-data in the associated file's root inode. HFS+ stores it in a central database
  • by saha (615847) on Monday May 01 2006, @09:10AM (#15236645)
    I very much wish for an updated filesystem for Mac OSX. I know that HFS plus (with journaling and meta-data searching where added later), I feel HFS + is showing signs of age. I was hoping when Apple first developed Mac OSX it had used the UFS system and then made a separate HFS+ partition for people who wanted to use a Mac OS9 on the PowerPC based Macs, but that didn't happen. Perhaps for the best at the time. Wilfredo Sánchez Vega wrote a whitepaper [wsanchez.net]on the reasoning for HFS + at the time

    So now with the Intel Macs and no need for Mac OS 9 support, Apple can tell all their developers that all Universal apps must be able to run on UFS. That way should Apple decide to adopt ZFS it should be a painless transition. Holding on to HFS + with the Intel Macs for this long will hamper any transition into a future filesystem. This will prepare Adobe and Microsoft to write their new Universal versions to be able to accept any type of filesystem and not rely on the resource fork of HFS

    That's my 2 cents.

  • I just wish we could come up with a network file system that's worth the trouble. Right now, I'm using a Linux server with three Macs (two Tiger, one Panther), and everything is over NFS. Most of the time, it works fine, but if there's a weird hiccup, then the Mac will freeze solid and has to be hard power-cycled. Also, some apps simply won't run from a network share (or they'll run, but one thing or another won't be right). Install that app to a local drive, and it works fine. And this isn't even to mention security issues.

    I've looked at AFP, but that essentially mounts the remote system as if it were an external drive, and assigns everything to the logged in user, so ownership, permissions, etc., are all really screwy. Plus that gets even worse if you use fast user switching -- now two people are independently trying to mount the same network drive, each claiming to own it outright. And it doesn't look as seamless as, say, simply going to /Server/Shared or /Server/Apps.

    SMB isn't much better.

    There's always AFS, but that's so bloody complicated that I'd take a lot of convincing before I seriously considered it.

    This isn't even to mention the problems that most apps have in working in a networked environment -- applications simply aren't designed for, say, networked home directories, and *especially* aren't designed to be running simultaneously on multiple systems. So if I've got Mail.app running in the den and I log in upstairs to check mail just before I go to bed, things could get messed up.

    I'm not sure there's even been a new network file system since the mid 90's, has there? Certainly, nothing with broad support that fixes some of these issues? All I want is UNIX filesystem features -- simple locking (I guess), owners, regular permissions. Doesn't even need to do ACLs. Transparently mounted so it looks like it's part of the local filesystem. And at least reasonably tolerant of network glitches, so a momentary drop at the server (or whatever else happens to screw NFS connections to the wall) doesn't put all apps which have even heard of the mount point into an uninterruptible kernel-level deep-freeze (what's the point of kill -9, dammit?). Is that so difficult?
  • Most excellent! (Score:3, Insightful)

    by csoto (220540) on Monday May 01 2006, @09:25AM (#15236755)
    ZFS is one of the more interesting filesystem developments of late. While the address space is nice, it's the data replication features included that make this a potential candidate to threaten the proprietary (and expensive) DR features of modern SAN and NAS storage systems. Need a synchronous or asynchronous mirror? No problem. Just issue a ZFS command on your OSX/Solaris/Linux server...
  • HFS is big endian (Score:4, Insightful)

    by KonoWatakushi (910213) on Monday May 01 2006, @09:35AM (#15236822)
    One of the reasons proposed over at Arstechnica has to do with byte ordering. Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.

    Even so, all of the other features of ZFS are worth much more than this. If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.

    ZFS is far from "just another filesystem," and comparing it to existing filesystems indicates a lack of understanding. Take a look at this presentation [opensolaris.org] for more information.

    • Re:HFS is big endian (Score:5, Informative)

      by BurntNickel (841511) on Monday May 01 2006, @10:31AM (#15237301)

      Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.

      While the non-native byte ordering does slow performance this only applies to metadata and not the contents of the files.

  • rewriting the Finder (Score:4, Informative)

    by Aram Fingal (576822) on Monday May 01 2006, @09:35AM (#15236825)
    I know this is just a little comment at the end of the story and not the main topic but the Finder really does need to be rewritten. It has a surprising lack of multithreading, even compared to Mac OS 9. This is most apparent (and most annoying) when you are navigating a slow network volume in the Finder. Quite often, you just can't do anything with but wait for the network to time out.
  • by adam1101 (805240) on Monday May 01 2006, @10:18AM (#15237193)
    The more I think about it, the more it makes sense for Apple to buy SUN. Their products nicely complement each other. Apple is strong in the consumer market and in the creative sector, SUN has good presence in the enterprise, tech and finance sectors. Apple has great brand value and knows marketing like no other computer vendor, SUN has technical excellence, but it's been struggling in the last years to actually sell their stuff. Their products portfolios have little overlap, and together they offer a very complete spectrum of computer products.

    Mac OS X is a great consumer OS, but performance at the high end is sub-par. For servers, Solaris is fast and scalable, has nifty features like ZFS and DTrace, but the UI is pretty crude. Imagine a merger of these. Looking at their market [yahoo.com] caps [yahoo.com], Apple can afford it.
    • by mhollis (727905) on Monday May 01 2006, @11:27AM (#15237798) Journal

      I like your comment. And the reason why I like it so much has to do with my (past) experience on a University system. Universities developed servers and file sharing with Macs using Sun's servers because Apple really didn't have a server. I mean you could put a Mac (usually an older one) on a network and tell it to share files with everyone but it lacked lots of stuff you would expect to have in a server and it tended to be pretty slow.

      I would argue that it was the University exposure that lead Apple to offer Ethernet on Macs. Appletalk was great and people hooked themselves up very quickly with Appletalk (you could buy cabling at your local Radio Shack or use almost any twisted-pair cabling, including electrical cables) but Ethernet was a lot faster and more reliable. I'll bet the folks who developed 10 Base-T Ethernet were thinking Appletalk when they came up with the design for the connector and the twisted pair.

      But I digress...

      I did a fair amount of work with a hard Science department and they all had Suns as servers. They were strictly Sun Unix for the geeks and they developed systems and applications on that model. But for those who actually had to function in an office environment, the Macs were standard. They used Microsoft's Office for memos, reports and spreadsheets and TeX for document publishing. Everything you did worked.

      Frankly, I think this legacy is part of the reason why Apple got fascinated with Unix again (that, and Jobs' NeXt company). It would be a good marriage. Apple's X-Serve RAIDs with Sun. Sweet!

  • by dottedlinedesign (754366) on Monday May 01 2006, @10:38AM (#15237352)
    But Dvorak said Apple was switching to Windows! How could this possibly be true?
    • Speaking as a Mac user who has used both, UFS has been a lot slower for me than HFS+.
    • ufs does not work with all software especially stupid applications made by microsoft
            • It helps to have knowledgeable moderators, but posts still have to be moderated to be useful for a general audience. In this case, the post in question doesn't tell you much if you don't happen to be very familiar with different file systems for OSX and the compatibility of OSX software with those file systems.

              Is the grandparent post flamebait? maybe not. Without minus_273's though, its probably not useful enought to be modded up either. Whether the moderation system is right or wrong, isn't the point here

          • "People just don't think that way until they've been conditioned to do so by Unix."

            Demonstrably not true. I've thought that way since I learned to read. In fact, I was confused the first time I dealt with an MS-DOS machine (before I ever heard of Unix), because the instructions showed commands in upper case and I thought I had to type them that way. Everything I do is based on identifying and classifying differences - "F" and "f" are patently not the same thing to me.

            People, at least people familiar with
      • by rsmith-mac (639075) on Monday May 01 2006, @08:47AM (#15236470)
        From the AirPort page:
        This issue is resolved in Mac OS X 10.1 and later.

        It's the same deal with the problem with Classic. All 3 items you link to are for OSX 10.0 and have been fixed since then. The number of UFS problems now is minute compared to then.

    • by Anonymous Coward
      Obligatory: Why are you waiting on your ass for a feature in an OS for which you have all the code? Drive the development of ZFS on Linux yourself. Ask for help when you get lost, but don't just sit around wasting oxygen.
      • by be-fan (61476) on Monday May 01 2006, @03:15PM (#15240025)
        Reiser4 is transaction-oriented, just like ZFS. The two actually use a similar principle (not journaling) to maintain consistency, based on COW'ing blocks in a tree, then committing the change atomically by swapping the pointer to the root of the tree in the parent node. Reiser4, however, instead of using the traditional block tree ZFS does, uses "dancing trees", which is kind of a B*-tree with ideas from log-structured filesystems mixed in.