Q: extremely blocky previews

I don't need answers that are not helpful.

ZEVO's ZFS implementation is put on top of OS X' VFS driver and supports all relevant functions that Aperture needs. Many programmers use ZFS with Aperture, and for good reasons, because we can't afford to entrust our valuable data to an outdated file system like HFS+ that has no built-in data integrity check and bit-rot recovery functionality like ZFS does.

ZFS for my pictures is non-negotiable. You might as well tell me to use Photoshop Lightroom, or just not say anything, if you can't provide constructive help FOR MY SETUP.

Besides, if Apple's Aperture really were using such crappy code that it breaks down when it's running on another file system type that supports the full set of semantics, or if Aperture, as a high-level, non-system application were using such low-level APIs that it would break running on another file system type, then the programmers should be fired, particularly if despite using such stunts the software is as slow as it is.

Application-level software is supposed to "just work" regardless of the file system type, as long as the regular semantics are supported. After all, we're talking about ZFS here, not FAT16 or something with ridiculous naming or feature limitations.

And no, ZFS is not the issue. Been using it for over a year, and the same library on the same disk with the same ZFS file system worked just fine on another machine until I did something to that machine I'm not allowed to write here, even though all I would be saying is public information.

ZFS is not the issue. The links provided warn people about not using the brain-dead FAT (read: MS-DOS) file system, which has file naming limitations and doesn't support the full POSIX file system semantics (permissions, symlinks, hardlinks, ACLs, EAs, etc.) non of which is an issue that has any relevance to ZFS, because it supports the full set of semantics, and then some. To quote from ZEVO's web site: http://getgreenbytes.com/solutions/zevo/

ZEVO’s file system is fully integrated into the Mac’s unique OS environment and implements quotas, ACLs, and the HFS+ programming interfaces like search-fs, id lookups, bulk access calls and resource fork stream access.

So what developers "specify" is not what is required, but what they happen to test on, because they can't test every possible permutation. However, sanely programmed application software will not assume anything but standard file system semantics.

To conclude that just because a particular file system is the default file system and the one the software is tested on, using a different file system that supports the full set of semantics software like Aperture is supposed to use is the cause for any problem is non-sequitur.

I'm a software developer myself, have a Sc.M. in computer science, so I don't need someone else to read me the writing on the software box. I can assess myself what is or isn't relevant to the problem. ZFS is not the problem. ZFS is only mentioned because it's the indirect cause for not being able to use my other computer anymore, because the direct cause is unmentionable on this forum.

Please, unless you have something relevant and helpful to say, don't post a reply.

I don't need another five people to chime in that ZFS isn't supported. It's widely used among photographers and well known to work just fine with Aperture; it also worked just fine for more than a year on two computers, until suddenly that particular library stopped working on one computer, while the very same library on the very same disk with the very same ZFS continued working on another computer.

For the sake of completeness, I just created a new library on the same ZFS drive and imported the same pictures, and it builds the previews properly.

So what we have is an issue specific to a particular library, but external to what's on the ZFS drive, because the same ZFS drive with the same library worked on another computer.

Chances are that something in ~/Library/Application\ Support/Aperture/ is gunked up, because what's in there is machine specific, while the Library itself is movable because I can attach the drive to a variety of computers, and only one of them has the issue.

Logical thinking looks at the variables when analyzing a problem, not at the constants, when comparing a broken scenario with a functional one. ZFS and the library are the constant, variables are the two different computers, two sets of preferences (elimiated by copying the preferences from the good computer to the bad), and two sets of Application Support folders, and two sets of who knows what, that's specific to a particular machine, such as e.g. iLife media caches, and other such things that are external to the library.