[TUHS] Illumos )

[tfb@tfeb.org (Tim Bradshaw)]

On 5 Jan 2015, at 17:04, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:

>  I'm afraid there's bias confirmation and a zeal for driving nails into coffins happening here.  Bear in mind that unix didn't even have fsck for a decade after its release (it appeared after v7 released), while conversely, zfs had the manual scrub command and other manual zfs recovery tools (which, much like fsck and icheck, et al, admittedly required expert knowledge to wield successfully) before it released. 

I own a vintage car, by which I don't mean the spurious things people now call 'vintage' but a car registered in 1930 or before.  It's a lovely thing to drive.  But it has no seatbelts, the fuel tank is over your knees and immediately behind the top of the engine (I try not to think about what that means in an accident) and rod brakes which you adjust with wingnuts.  I would not be happy with these features in a new car.

> Yes, the default is that the system will panic or pass over a zfs it can't mount, but that's by design and when I was in that situation myself, even as a zfs noob, I managed to figure out how to recover without damaging my pool.  Would you care to compare this experience to some of the battles we've all personally waged with fsck?  

Again: the 'fsck on old systems' comparison is simply not relevant, sorry: we have learnt a lot of stuff since then.  One thing we should have learnt is that you want code to run with the minimum possible privilege, because running things with too much privilege has led to appalling disasters which I'm sure I don't need to mention.  That means, for instance, that you should run nothing in the kernel that does not have to be there.  One thing which clearly does not have to be there is consistency checkers and debuggers for filesystems, of whatever kind. There is absolutely nothing in the design of ZFS which prevents that being done.

> In the unix tradition, zfs is a designed and deliberate iteration (innovation) on the filesystem concept, not a "pragmatic," good-enough, minimum viable product hip-shot, and the obvious fact that it isn't what we're used to doesn't make it bad.  While there are certainly plenty of Solaris coffin nails, this ain't one.

I'm extremely happy that ZFS is not a traditional filesystem, because the traditional volume-manager / filesystem model sucks, to put it mildly: I have spent enough of my life dealing with it that I just want it to be over. I just want ZFS to be properly engineered.  Instead, what will (has, probably) happen is a ZFS clone will appear for Linux, which will be properly engineered.  Such is the fate of Solaris: pride does, indeed, come before a fall.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/def16a4a/attachment.html>