Re: [zfs-discuss] pls discontinue troll bait was: Yager on ZFS and ZFS
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, Ah - I see we have another incompetent psychic chiming in - and judging by his drivel below a technical incompetent as well. While I really can't help him with the former area, I can at least try to educate him in the latter. ... Excerpt 1: Is this premium technical BullShit (BS) or what? Since you asked: no, it's just clearly beyond your grade level, so I'll try to dumb it down enough for you to follow. - 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. Do you by any chance not even know what 'continuous data protection' is? It's considered a fairly desirable item these days and was the basis for several hot start-ups (some since gobbled up by bigger fish that apparently agreed that they were onto something significant), since it allows you to roll back the state of individual files or the system as a whole to *any* historical point you might want to (unlike snapshots, which require that you anticipate points you might want to roll back to and capture them explicitly - or take such frequent snapshots that you'll probably be able to get at least somewhere near any point you might want to, a second-class simulation of CDP which some vendors offer because it's the best they can do and is precisely the activity which I outlined above, expecting that anyone sufficiently familiar with file systems to be able to follow the discussion would be familiar with it). But given your obvious limitations I guess I should spell it out in words of even fewer syllables: 1. Simulating CDP without actually implementing it means taking very frequent snapshots. 2. Taking very frequent snapshots means that you're likely to interrupt background defragmentation activity such that one child of a parent is moved *before* the snapshot is taken while another is moved *after* the snapshot is taken, resulting in the need to capture a before-image of the parent (because at least one of its pointers is about to change) *and all ancestors of the parent* (because the pointer change will propagate through all the ancestral checksums - and pointers, with COW) in every snapshot that occurs immediately prior to moving *any* of its children rather than just having to capture a single before-image of the parent and all its ancestors after which all its child pointers will likely get changed before the next snapshot is taken. So that's what any competent reader should have been able to glean from the comments that stymied you. The paragraph's concluding comments were considerably more general in nature and thus legitimately harder to follow: had you asked for clarification rather than just assumed that they were BS simply because you couldn't understand them you would not have looked like such an idiot, but since you did call them into question I'll now put a bit more flesh on them for those who may be able to follow a discussion at that level of detail: 3. The file system is in a better position to handle CDP than some external mechanism because a) the file system knows (right down to the byte level if it wants to) exactly what any individual update is changing, b) the file system knows which updates are significant (e.g., there's probably no intrinsic need to capture rollback information for lazy writes because the application didn't care whether they were made persistent at that time, but for any explicitly-forced writes or syncs a rollback point should be established), and c) the file system is already performing log forces (where a log is involved) or batch disk updates (a la ZFS) to honor such application-requested persistence, and can piggyback the required CDP before-image persistence on them rather than requiring separate synchronous log or disk accesses to do so. 4. If you've got full-fledged CDP, it's questionable whether you need snapshots as well (unless you have really, really inflexible requirements for virtually instantaneous rollback and/or for high-performance writable-clone access) - and if CDP turns out to be this decade's important new file
Re: [zfs-discuss] pls discontinue troll bait was: Yager on ZFS and ZFS
On Sat, 17 Nov 2007, can you guess? wrote: Ah - I see we have another incompetent psychic chiming in - and judging by his drivel below a technical incompetent as well. While I really can't help him with the former area, I can at least try to educate him in the latter. I should know better than to reply to a troll, but I can't let this personal attack stand. I know Al, and I can tell you for a fact that he is *far* from technically incompentent. Judging from the length of your diatribe (which I didn't bother reading), you seem to subscribe to the if you can't blind 'em with science, baffle them with bullshit school of thought. I'd take the word of any number of people on this list over yours, anyday. HAND, -- Rich Teer, SCSA, SCNA, SCSECA, OGB member CEO, My Online Home Inventory URLs: http://www.rite-group.com/rich http://www.linkedin.com/in/richteer http://www.myonlinehomeinventory.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] pls discontinue troll bait was: Yager on ZFS and ZFS
troll bait Rich Teer wrote: I should know better than to reply to a troll, but I can't let this personal attack stand. I know Al, and I can tell you for a fact that he is *far* from technically incompentent. Judging from the length of your diatribe (which I didn't bother reading), you seem to subscribe to the if you can't blind 'em with science, baffle them with bullshit school of thought. I'd take the word of any number of people on this list over yours, anyday. HAND, I'm sure this troll will reply to you as he did to me. I just can't help laughing at his responses anymore. I do find it odd that someone has so much time on their hands to just post such remarks. It's as if they think they are doing themself or the world a flavor. /troll bait ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] pls discontinue troll bait was: Yager on ZFS and ZFS + DB + fragments
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
