Slashdot Mirror
ZFS Set To Eventually Play Larger Role in OSX
BlueMerle writes with the news that Sun's ZFS filesystem is going to see 'rudimentary support' under OSX Leopard. That's a stepping stone to bigger and better things, as the filesystem will eventually play a much larger role in Apple OS versions. AppleInsider reports: "The developer release, those people familiar with the matter say, is a telltale sign that Apple plans further adoption of ZFS under Mac OS X as the operating system matures. It's further believed that ZFS is a candidate to eventually succeed HFS+ as the default operating system for Mac OS X -- an unfulfilled claim already made in regard to Leopard by Sun's chief executive Jonathan Schwartz back in June. Unlike Apple's progression from HFS to HFS+, ZFS is not an incremental improvement to existing technology, but rather a fundamentally new approach to data management. It aims to provide simple administration, transactional semantics, end-to-end data integrity, and immense scalability."
Macs are really going to stink if Apple changes their default operating system to ZFS. ZFS is a file system.
Non standard tools and such
Uh, Mac OS X is certified standard UNIX. Solaris is also certified standard UNIX. And they're both fully POSIX compliant.
What are some examples of non-standard tools?
Unless I'm mistaken, this will mean the true end to resource forks on the MacOS. For those of you who aren't familiar with them, resource forks were a part of a file under the Classic MacOS (OS 9 and before) that contained icon information, filetype and creator codes, etc. This part of the file was only supported under the HFS and HFS+ filesystems, meaning the resource fork would get lost if you copied a file to a non-HFS/HFS+ filesystem (this is why files copied to FAT filesystems in the old days often wouldn't reopen on a Mac. It also explains the "Mac OS X" folder with underscored-dot files from archives created with OS X's built-in zip utility). With OS X, Apple rolled the resource fork into the "data fork" portion of the file, meaning the information was still there for legacy purposes. However, this is only supported under apps that know where to find the information. This change has the potential to cause some headaches for shops that have legacy files spanning several decades. OTOH, I'll be glad to see it finally go...
This guy's the limit!
There is a in-memory checksum check for all data that is read, yes. If the checksum doesn't match ZFS tries to read the same data from another disk, in a mirror/RAID-Z setup.
Sun is the new Bell Labs.
Watch for the robotics coming out, very quietly, from Sun in the next 10 years.
Website Hosting
What are you smokeing - what ever it is, pass it this way. Non-standard or 'does not conform to the bastardised standards which GNU have embraced and extended'. Case in point, look at the number of nimrods who assume gnu grep and use gnu specific switches for their make scripts.
It isn't Solaris that it is non-standard, it is those who insist on using GNU tools and their extensions to the standard which are the non-standard.
Are there memory bus or in-memory check for integrity of data read from ZFS? What about applications?
They have defined what they mean by that claim already: they have a checksum (256-bit, I think) on every block, and that checksum is checked from the OS when the block is read.
This will catch some errors that might otherwise go uncaught, which is important for servers that move a lot of data around.
It will not catch a memory error at the wrong time, or a processor error that stores the wrong value, or an error in the brain of the person who reads the data from the screen.
Social scientists are inspired by theories; scientists are humbled by facts.
Hardly! ZFS have provisions for any number of "forks" in the file system, called "extended attributes" in ZFS. If Apple migrates to ZFS they have every chanse to use these attributes to provide for quite a seamless integration with previous filsystems. The file system is open source and Apple can prettymuch do what they like or need. Even NTFS have these features but MS seems to ignore them due to backwards compatability issues with FAT filsystems and Windows APIs
You know.. Wikipedia is very handy to look these things up. Please do. http://en.wikipedia.org/wiki/ZFS
- Henrik
- when the Shadows descend -
IIRC, the block checksums are stored in the inode, not with the individual blocks. It turns out that one of the main failure modes of modern disks isn't reading a few bits wrong, but missing slightly on a seek and actually returning the wrong block! Block-included checksums won't find this, since it's still a valid block...
I don't think UFS using community would be happy about Spotlight anyway.
Spotlight in current form tries to index every single source file, huge framework headers and there is no practical way to stop it. I have tried the Privacy pane as suggested and no, it doesn't explain my 130 MB of spotlight metadata after installing Developer tools and couple of GNU libraries.
If they have checked the NeXT history, they would figure the UFS is the default,supported Filesystem on NeXT. As OS X is a mix of NeXT with FreeBSD and Cocoa/Carbon, it is pretty natural that UFS gets into it a bit lately but finally.
I can imagine what Apple needs for supporting ZFS on startup volumes. Complete metadata and resource support. They could be happy with their ext3 plain filesystem but Apple using professionals REALLY label their files, sometimes change their icons, sometimes has to FORCE OS to open a file with a different version of suite (e.g. Quark 7 vs 6), add comments to them and professional software developers like Adobe still stores critical data on resource forks.
If there is a way to make ZFS support all those features without huge hacks (like the ZIP _resource stuff), they would give up their HFS+. Another thing is, it must support every serious software (non hack) backwards. You may find yourself using a application from 2001 written in Carbon under OS X and only it can provide the tool you require.
I am saying these since some elitists think Apple is backwards and stupid still supporting resource forks and implement special features to OS X just to give minimum compatibility with old applications.
Before critising HFS+ and suggesting Apple to use plain, Unix filesystems, they should sit around in a professional environment such as a DTP house, Movie studio and see how all those "childish" "backwards" features are used by professionals in job.
This is not a post against ZFS, I am just trying to explain why Apple can't magically move to another filesystem just because it has better features. Not even mentioning the "overhead" required by ZFS and the fact that there are some 2k/4k (Cinema) edit environments which you can't even enable journaling let alone adding another layer of overhead.
Also while writing these, if I only used plain Unix tools without any "native Mac" Application, e.g. use OS X as Darwin with X11, UFS would be my choice of filesystem.
According to the Single Unix Standard, only Mac OS X 10.5 (Leopard) can be considered "Unix". And only when deployed on Intel-based Macs. Previous versions must be considered like Linux: "Unix-like".
FWIW, Sun's operating system (SunOS) has been fairly close to Unix standards over its lifetime. In fact, the official version of System V release 4 was written by Sun and called SunOS 5, integrated into Solaris 2
Why is anyone even having this argument? GNU means "Gnu's NOT Unix" for a reason...
The Wizard utters the word 'frobnoid!' and cackles gleefully
It's true that you can't expand a RAID-Z set (I think, anyway -- if you replace all of the drives, one at a time, does that work?), but you can add another RAID-Z set, and expand the pool.
That's the big thing in ZFS, combining all of the resources into a pool, rather than treating disks (or groups of disks) as part of a volume. The other part of this was making filesystems nearly as light-weight as directories.
My plan is to use twinned drives, adding them as a mirror to the pool. I can replace each drive individually, let it re-silver, and then do the same with the other, to expand it, or I can simply add another pair of drives to the pool, and get more space that way. There are advantages and disadvantages to each.
Oh, as for resource forks -- the model that Sun is choosing (as are some others) is that the extended attributes are treated as sub-files to a directory. I'm not sure that simply going to a directory is not a better idea, but that has a whole slew of its own problems. It's a bit ironic, really -- Apple had an idea from the beginning, and every application was prepared to deal with it, but nobody else did the same thing. Then, when Apple went with the flow, everyone else started trying to do what Apple did... and none of the applications are prepared for it.
I'm not sure how it'll all turn out.