I've been observing two threads on zfs-discuss with the following
Subject lines:
Yager on ZFS
ZFS + DB + "fragments"
and have reached the rather obvious conclusion that the author "can
you guess?" is a professional spinmeister, who gave up a promising
career in political speech writing, to hassle the technical list
membership on zfs-discuss. To illustrate my viewpoint, I offer the
following excerpts (reformatted from an obvious WinDoze Luser Mail
client):
Excerpt 1: Is this premium technical BullShit (BS) or what?
------------- BS 301 'grad level technical BS' -----------
Still, it does drive up snapshot overhead, and if you start trying to
use snapshots to simulate 'continuous data protection' rather than
more sparingly the problem becomes more significant (because each
snapshot will catch any background defragmentation activity at a
different point, such that common parent blocks may appear in more
than one snapshot even if no child data has actually been updated).
Once you introduce CDP into the process (and it's tempting to, since
the file system is in a better position to handle it efficiently than
some add-on product), rethinking how one approaches snapshots (and COW
in general) starts to make more sense.
------------- end of BS 301 'grad level technical BS' -----------
Comment: Amazing: so many words, so little meaningful technical
content!
Excerpt 2: Even better than Excerpt 1 - truely exceptional BullShit:
------------- BS 401 'PhD level technical BS' ------------------
No, but I described how to use a transaction log to do so and later on
in the post how ZFS could implement a different solution more
consistent with its current behavior. In the case of the transaction
log, the key is to use the log not only to protect the RAID update but
to protect the associated higher-level file operation as well, such
that a single log force satisfies both (otherwise, logging the RAID
update separately would indeed slow things down - unless you had NVRAM
to use for it, in which case you've effectively just reimplemented a
low-end RAID controller - which is probably why no one has implemented
that kind of solution in a stand-alone software RAID product).
...
------------- end of BS 401 'PhD level technical BS' ------------------
Go ahead and lookup the full context of these exceptional BS excerpts
and see if the full context brings any further enlightment. I think
you'll quickly realize that, after reading the full context, this is
nothing more than a complete waste of time and that there is nothing
of technical value to learned from this text. In fact, there is very,
very little to be learned from any posts on this list where the
Subject line is either:
Yager on ZFS
ZFS + DB + "fragments"
and the author is: "can you guess? <[EMAIL PROTECTED]>"
I'm not, for a moment, suggesting that one can't learn *something*
from the posts of the author "can you guess?
<[EMAIL PROTECTED]>"... indeed there are significant
spinmeistering skills to be learned from these posts; including how to
combine portions of cited published technical studies (Google Study,
CERN study) with a line of total semi-technical bullshit worthy of any
political spinmeister working withing the DC "Beltway Bandit" area.
In fact, if I'm trying to conn^H^H^H^H talk someone out of several
million dollars to fund a totally BS research project, I'll pay any
reasonable fees that "can you guess?" would demand. Because I'm
convinced, that with his premium spinmeistering/BS skills - nothing is
impossible: pigs can fly, NetApp == ZFS, the world is flat .... and
ZFS is a totally deficient technical design because they did'nt
solicit his totally invaluable technical input.
And.. one note of caution for Jeff Bonwick and Team ZFS - lookout ...
for this guy - because his new ZFS competitor filesystem, called,
appropriately, GOMFS (Guess-O-Matic-File-System) is about to be
released and it'll basically, if I understand "can you guess?"'s email
fully, solve all the current ZFS design deficiencies, and totally
dominate all *nix based filesystems for the next 400 years.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/
Graduate from "sugar-coating school"? Sorry - I never attended! :)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
