ZFS Shows Up in New Leopard Build

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?"

Comments

copy-on-write

[Mr2cents]

FTA:

Makes use of copy-on-write; rather than overwriting old data with new data, it writes new data to a new location and then overwrites the pointer to the old data Wouldn't that pose a problem for mmap?

Not a likely replacement...

[qwertphobia]

If it is not meant to replace HFS+, could there be any other reasons to support ZFS?" Well, OSX 10.4 already supports FAT16, FAT32, and HFS, HFS+ (case sensitive and case-insensitive) and UFS. I don't see any obvuious conclusion that HFS+ is on the way out. Now if the OSX kernel AND os both support a ZFS-formatted partition as a boot partition, we might find it as an accceptable replacement, but otherwise I would think ZFS will be added for large enterprise SAN RAIDs and such.

ZFS vs HFS vs NTFS?

[Bonker]

The tech behind ZFS at least sounds very impressive, but I have to wonder how useful it is for workstation drives.

I've never found plain-Jane posix permissions to be all that useful on anything other than the most basic of server environments.

HFS has going for it all the fun stuff we've come to love apple for, such as transparent file customization like icons, labels, meta data, and whatnot through resource forks. I assume that these can be made to work with ZFS by making hidden files.

What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented. ACL permissions are a godsend for people responsible for running a file store that's used by humans as opposed to automated processes. NTFS also has a great deal of capacity for meta-data, although not to the same level as HFS.

NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.

Re:ZFS vs HFS vs NTFS?

[pesc]

NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.

I wish MS would let us. NTFS is worthless if you don't run Windows. And it hinders interoperability with other systems because its implementation and disk layout is secret/patented.

Why, do you think, there is no stable implementation that can write NTFS volumes (other than the MS implementation)?

Contrast this with ZFS which is released under an open source license.

Re:ZFS vs HFS vs NTFS?

[UtucXul]

NTFS is one of the few worthwhile things that's ever come out of Redmond. I wish more people would spend a bit learning from it without throwing it away simply because it's MS bloat.

I think the negative opinion some people (including me) have of NTFS come not directly because it is from MS, but come from the incompatibility with everything else. I can't (reliably) read/write to it from a Mac, Linux, or Sun. That leaves only people totally in the MS camp able to use it. It may have some nice technical features, but I can't ever see them, so it is a little hard to be impressed or care about them too much.

Re:ZFS vs HFS vs NTFS?

[More Trouble]

HFS has going for it all the fun stuff we've come to love apple for, such as transparent file customization like icons, labels, meta data, and whatnot through resource forks. I assume that these can be made to work with ZFS by making hidden files.

You assume correctly, since most of that business is taken care of with Bundles. This is why it more or less works on UFS, which is already supported on Mac OS X, and has been for years. Forks & whatnot are really a legacy idea.

What I'd really like to see is both that kind of functionality along with NTFS's really excellent ACL permission system implemented.

That's funny! The HFS+ ACL system is Microsoft's ACL system, much to the chagrin of the Unix community.

:w

Re:What a moron

[Udo Schmitz]

It's called compatibility.

Wouldn't full NTFS support (or well, support for any FS more in use then ZFS today) make more sense?

Re:What a moron

[metamatic]

Wouldn't full NTFS support (or well, support for any FS more in use then ZFS today) make more sense?

Yeah, I mean it's not like NTFS is defined and controlled by an organization renowned for its hostility to other platforms, reluctant to document things in a way that other people can implement them, and scared of interoperability, is it?

Re:Reasons to support? Servers

[kestasjk]

It sounds good, but I think migrating for it just a tad extreme given that it will be implemented for Linux pretty quickly. We're talking about neat new features here, it'll re-enforce or make easier backups and redundancy, but it's not a to-die-for solution that will solve all your problems. There's no way I'd drop a fully configured server installation which does what I need for a new filesystem.

By the way it's nice to see dtrace, open source Java, and now ZFS coming out of Sun recently. I almost feel sorry for how little they get out of a lot of their innovations, they remind me of Bell Labs just before they died.

Secure Delete?

[HTH NE1]

Wouldn't that pose a problem for mmap?

I think it would pose a problem for secure deletes. Try to obliterate a file by overwriting it with garbage, you end up writing somewhere else instead? Would the next overwrite attempt get the original location or would you have to write enough garbage to cycle over all the free space of the volume? Considering how large these volumes can get, that's a lot of boiled oceans for a multi-pass secure delete.