Re: ZFS honesty

From: 韓家標 Bill Hacker <askbill_at_conducive.net>
Date: Sun, 06 Jan 2008 22:58:49 +0000
Ivan Voras wrote:
> 韓家標 Bill Hacker wrote:
> 
>> JM2CW, but the level of 'traffic' on this list in re 
>> still-experimental-at-best ZFS is distracting attention from issues 
>> that are more universal, critical to more users and uses - and more in 
>> need of scarce attention 'Real Soon Now'.
>>
>> It almost begs dismissal of ZFS posts to the bespoke list out-of-hand.
>>
>> ZFS is still eminently 'avoidable' for now.
>>
>> Reports of I/O problems, drivers that can corrupt data on *UFS* are a 
>> whole 'nuther matter..
> 
> For my part it's because I'm "desperate" for a good file system, and ZFS 
> seemed to be "it" for a while. I'd also settle for any other, including 
> a stable version of UFS that's pleasant to work with on TB-sized drives 
> (Sun's UFS? BLUFFS?), XFS, Ext4, LFS, HAMMER, whatever.
> 
> I've tried contacting the author of BLUFFS, but without optimistic results.
> 

None are perfect. But ZFS is just *too* new. And not just on *BSD.
If IBM had not already had GPFS, Sun might never even have 'invented' ZFS.

The 'other' ones with the longest 'history' - where known-problems have knwon 
avoidance/workaround, may well be XFS and JFS. Heavy-lifters iwht commercial 
track-records, both.

Not to mention UFS...

I'm still in the practice of 'slicing' into 50 GB or so - 100GB max - no matter 
*what* the drive size is.

So where's the 'beef'?

Half-terabyte *files*?  I surely hope not..

At some point too many eggs (files) in one basket just makes b/u restore a 
nightmare.

There are no silver bullets.

Drives fail. Controllers fail, and sometimes had done so long before anyone 
noticed they were subtly corrupting data. So even RAID arrays and offline b/u 
can fail one..

ZFS doesn't 'fix' all that - just approaches a fix in an all-software manner.

Other failings aside, there is an overhead penalty for all the 'handling'.

Coders may believe in that. It's what they do.

I'll take simplicity, redundant hardware.  And compartmentalization.

Faster, cheaper, lasts a long time.

And takes more manageable sized chunks out of yerass when it DOES go tits-up. 
As that all do.

Bill
Received on Sun Jan 06 2008 - 21:58:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC