ZFS (was Reliable Firewire drives)

John C. Welch jwelch at bynkii.com
Tue Feb 12 07:44:38 PST 2008


On 02/12/2008 09:26 AM, "Dan Shoop" <shoop at iwiring.net> wrote:

>> The story could also be used to point out that block-wise copies of
>> file systems are a  bad idea.  It is obvious that you should do
>> logical copies of the file system (copying file by file), to avoid
>> carrying block-level faults (file system, hardware error, or
>> otherwise) to your precious backup copy.
>> 
>> The story is about poor recovery planning first, bug in file system
>> second.
> 
> 
> Neither one should have occurred had only the sysadmins been
> exercising any modicum of due diligence.

They were. They had a planned upgrade. The bug hit before they could. Not
upgrading just because you can is the definition of "due diligence".

> 
> I suppose John will say that this is his point, that it's not a magic
> pill, but like in every fairy tale I've ever seen the hero never use
> the old version of the magic spell either nor does he slay the wrong
> dragon or try to win the affections of the princesses aging stepmother.

In fairy tales, there's no versioning. It's magic. That's why the perfection
of ZFS or any software is a fairy tale. Because for it to be perfect, it
relies on magic and magical thinking.

I haven't yet seen claims that ZFS will make your teeny peenie larger, or
whip up a great fondue, but they aren't *far* from it. The computer industry
is always looking for the next magic spell, and as such, they are doomed to
failure.

ZFS is, without doubt, one of the first rethinking of the basic FS that
isn't a "Database Filesystems are the magical future", and it has many good
points. However, it is not the perfect FS for all needs. It is a useful tool
when used correctly, nothing more.

> 
> One might point out that one of ZFS's engineering goals is to assure
> block-wise errors are detected if not fixed, and has a lot of magic
> associated with this; but using an unstable and outdated version (by
> well over a year) and ignoring updates that address significant major
> fixes, is ignoring your job. Your tools can only do their tricks if
> you keep them in working order. I don't expect a broken hammer to
> drive nails and shouldn't complain when its head flies off as I try to
> drive a nail and hits me in the face.

However, you also don't trade in a working hammer because there's a new
version out when you're in the middle of a nail. You plan your new hammer,
and upgrade when it's appropriate. Sometimes that does in fact, take a year.
Sometimes it takes days.

Perhaps if there were less magical thinking about ZFS, the assumption that
you can delay bug patches wouldn't have happened and they'd have upgraded
sooner. However, that would require the industry to stop shoving its
collective ego in every orifice that slows down long enough, and that's just
never going to happen.

-- 
John C. Welch         Writer/Analyst
Bynkii.com              Mac and other opinions
jwelch at bynkii.com




More information about the MacOSX-admin mailing list