6 Jan
2015
6 Jan
'15
9:37 p.m.
On 5 Jan 2015, at 17:04, Jacob Ritorto <jacob.ritorto(a)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.