Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Just been reading up on ZFS, some of the features sound very interesting though not particularly useful to me at this present moment. I wonder if ZFS will end up lasting a long time as a sort of 'standard' filesystem such as FAT?

That would be completely and utterly wonderful, but unless Microsoft signs on (and I don't see any evidence they would), and the Linux kernel people stop rubbishing the design - they don't like the fundamental structure of ZFS, which isn't layered conveniently enough for Linux file system gurus) it's unlikely it'll become a de-facto standard any time soon.

Would be nice though, especially if different operating systems found ways to keep "their" system files in directories separate from others, so, for example, Mac OS X, GNU/Linux, and Windows could all be installed on the same disk, able to read the same files in the exact same way. Imagine that combined with virtualization. That'd take some work and cooperation though...
 
OT: CrashPlan [was: borrow 2 TB for a week or so]

can someone please start a business of renting a few TB drives for a week? Archive and install is nice and usually works well. … If only I could borrow a 2 TB drive for a week or so. Any takers? :rolleyes:

Consider CrashPlan (FAQ) — fully functional 30 day free trial of CrashPlan Pro.
 
See also How ZFS Works (PDF, April 2007) from OpenSolaris Day at Sun Tech Days — St. Petersburg, Russia 2007. I haven't digested the PDF yet but I imagine that it's a more recent version of ZFS: the last word in file systems (PDF, 2005) that's available from Sun's Learning Center.

Thanks for the links. I've been studying up on ZFS since I played with early versions of it first hand a couple of years ago. From everything I've played with, and everything I've read, this will put Apple firmly on top of the file system debate for years to come.

This announcement is the reason I'll be watching the keynote.
 
More reliable, more features, faster...

ZFS is a great replacement for HFS+. If you have an app that doesn't like it for some reason, you can probably leave it in an HFS+ volume and have it work properly. The benefits of ZFS really make it a revolutionary upgrade.

Even home users with a single disk will gain several benefits. A system with a single hard drive will be more reliable with ZFS than with HFS+. Copy-on-write means the drive data won't become corrupted by power failures or other sudden shutdowns. Checksums will help to avoid many physical drive errors.

Also, the system will very likely be much more responsive and have improved performance when pushed to its limits when using ZFS. Advanced I/O scheduling should improve system responsiveness when accessing large amounts of data. This should provide a performance benefit in some situations for many applications that may become I/O restricted when accessing a lot of data such as video, audio, images, 3D models, databases, or game data files.

Of course, in systems using multiple drives the performance and reliablity benefits become even greater.
 
I am VERY excited to buy my disgustingly over-spec'ed Mac Pro now (once I return from the big mudhole, that is). The wikipedia page mentioned this:

ZFS lacks transparent encryption, although there is an OpenSolaris project underway
Does that mean there is no current filesystem encryption benefits to ZFS?
 
I am VERY excited to buy my disgustingly over-spec'ed Mac Pro now (once I return from the big mudhole, that is). The wikipedia page mentioned this:


Does that mean there is no current filesystem encryption benefits to ZFS?
Yes, it does... ZFS currently doesn't support encrypting files at the filesystem level, unlike NTFS, which does have this feature.
 
How ZFS Works: 5th April English predecessor to the 25th April Russian version

Ehrm.... that PDF is in Russian... :confused:
Oh … the Russian PDF was produced on 25th April, the English PDF that I downloaded (from the same URL, I'm almost certain) was produced on 5th April.

Although I see no 'copyright' on the document: it may be inappropriate for me to share it, so I guess you'll have to wait for the OpenSolaris community to publish the English version.

Sorry!
 
ZFS, HFS+, resource forks, CIFS, data streams, VFS, VFSFT_XVATTR, extended attributes

… unlikely [ZFS will] become a de-facto standard any time soon.

My limited understanding is that ZFS need not be a de-facto standard, if it will support the various files systems required/desired by Linux and other communities.

The question of layers, or perceptions thereof, is definitely thought-provoking.

Would be nice though, especially if different operating systems found ways to keep "their" system files in directories separate from others, so, for example, Mac OS X, GNU/Linux, and Windows could all be installed on the same disk, able to read the same files in the exact same way.

From what I can gather, ZFS may well make possible what you describe, or something similar.

Also, as I'm learning about FUSE and MacFUSE, I imagine that much of what you describe may ultimately be possible without ZFS (although my strongest sense is that Apple's implementation of ZFS will make disk and file system management extraordinarily easy).

Imagine that combined with virtualization. That'd take some work and cooperation though...

FWIW here are my current thoughts on the subject: ZFS, HFS+, resource forks, CIFS, NTFS ADS data streams, VFS, VFSFT_XVATTR, extended attributes. I would normally wait for WWDC, but current coincidences are leading me to piece together the jigsaws, as best I can, in advance…

Regards
Graham
 
No one has mentioned that ZFS, at least on Solaris, currently supports compressed filesystems.

The fact that Apple is adopting ZFS as its base volume manager / file system is huge, IMO.
 
Does this mean your boot volume will get cluttered with ".DS_Store" and ".SuchAndSuchFile.ext" files now, or is there some way to include the old school Mac OS metadata in ZFS without resorting to that?
 
ZFS extended attributes negate the need for .DS_Store and ._ dot underscore files

Does this mean your boot volume will get cluttered with ".DS_Store" and ".SuchAndSuchFile.ext" files now…

IMO, extremely unlikely. Wikipedia Comparison of file systems section on metadata seems to be a fair point of reference in this instance.

Incidentally whilst .DS_Store and ._ dot underscore files may appear to be undesirable clutter, they are simply most often an alternative presentation of desirable data (often metadata) on file systems that do not support extended attributes or resource forks in the 'rich' ways preferred by applications such as Finder and Path Finder.

Off-topic from ZFS, see this comment for a hint regarding Finder's use of ._ files during copy routines — somewhat surprisingly, when the file being copied has neither resource fork nor extended attribute.
 
One thing I have noticed with OS X is that while the CPU is shared well, the disk isn't.

If you have one app that makes heavy use of the disk, OS X is not able to give other apps a look in, they just beach ball and go crazy. I hope along with this new filesystem they improve I/O scheduling.
 
One thing I have noticed with OS X is that while the CPU is shared well, the disk isn't.

If you have one app that makes heavy use of the disk, OS X is not able to give other apps a look in, they just beach ball and go crazy. I hope along with this new filesystem they improve I/O scheduling.
I've noticed the same thing, more or less. Disk I/O scheduling is done within ZFS itself, so that aspect will definitely change from the current HFS+ / OS X implementation.
 
Does anyone know if i can format my disk with the new filesystem:
Code:
http://zfs.macosforge.org/trac/wiki/downloads
and then install leopard on that?
 
Does anyone know if i can format my disk with the new filesystem:
Code:
http://zfs.macosforge.org/trac/wiki/downloads
and then install leopard on that?

An obvious answer could be had by going to that same site and reading the FAQ:

Can I boot off of ZFS?

Not yet but we are working on it. Since booting off of ZFS requires changes to other parts of the system we won't likely be able to release it in a simple tarball. However our goal is to be able to have it available for the next OS X release if we can.

And the bits they are talking about are the bits requires to get EFI to understand ZFS enough to be able to fine the bootable file within a ZFS pool. I would imagine that this is a not-small undertaking, and requires an EFI update.

Since I am in the middle of writing things for EFI, I do not envy the people who have to do that work (a couple of whom I have now talked to).
 
An obvious answer could be had by going to that same site and reading the FAQ:

And the bits they are talking about are the bits requires to get EFI to understand ZFS enough to be able to fine the bootable file within a ZFS pool. I would imagine that this is a not-small undertaking, and requires an EFI update.

Since I am in the middle of writing things for EFI, I do not envy the people who have to do that work (a couple of whom I have now talked to).

Not necessarily; you could have a very small HFS+ partition with the necessary files required to get ZFS to mount. That is no different to how EFI is meant to act by default, where by there is a mini-fat patition, and use that to mount, in the case of Windows, the NTFS partition.
 
Not necessarily; you could have a very small HFS+ partition with the necessary files required to get ZFS to mount. That is no different to how EFI is meant to act by default, where by there is a mini-fat patition, and use that to mount, in the case of Windows, the NTFS partition.

Except that the EFI System partition is not actually used by MacOS X. The EFI firmware understands HFS (at least read-only), and understands HFS+'s boot-file pointers (in the volume headers). I don't understand the MBR boot process completely (we are working on that now), but the EFI layer in Mac's does not seem to understand NTFS.

All the evidence I have points to a special driver in Apple's EFI firmware that knows how to bootstrap MBR boot records (as long as they conform to certain rules).
 
Except that the EFI System partition is not actually used by MacOS X. The EFI firmware understands HFS (at least read-only), and understands HFS+'s boot-file pointers (in the volume headers). I don't understand the MBR boot process completely (we are working on that now), but the EFI layer in Mac's does not seem to understand NTFS.

All the evidence I have points to a special driver in Apple's EFI firmware that knows how to bootstrap MBR boot records (as long as they conform to certain rules).

If they did have ZFS, I wonder if they would limit it to the Core 2 Duo range as the performance of it on 32bit machines leaves alot to be desired (due to the checksum overhead etc.). It would require a great undertaking though.

LIke I said, have a mini HFS+ partition, plonk the kernel and necessary drivers in there - and use that is the bouncing point. When you upgrade the kernel in the case of an update, on reboot there should be an auto-sanity check to ensure that the kernel on the zfs partition is equal to what is in the HFS+ Book partition, there are charges - the HFS+ patition is updated.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.