In the previous and current responses, you seem quite determined of others misconceptions. Given that fact and the first paragraph of your response below, I think you can figure out why nobody on this list will reply to you again.
can you guess? wrote: >> No, you aren't cool, and no it isn't about zfs or >> your interest in it. It was clear from the get-go >> that netapp was paying you to troll any discussion on >> it, >> > > It's (quite literally) amazing how the most incompetent individuals turn out > to be those who are the most certain of their misconceptions. In fact, there > have been studies done that establish this as a statistically-significant > trait among that portion of the population - so at least you aren't alone in > this respect. > > For the record, I have no connection with NetApp, I have never had any > connection with NetApp (save for appreciating the elegance of their > products), they never in any way asked me to take any part in any discussion > on any subject whatsoever (let alone offered to pay me to do so), I don't > even *know* anyone at NetApp (at least that I'm aware of) save by > professional reputation. In other words, you've got your head so far up your > ass that you're not only ready to make accusations that you do not (and in > fact could not) have any evidence to support, you're ready to make > accusations that are factually flat wrong. > > Simply because an individual of your caliber apparently cannot conceive of > the possibility that someone might take sufficient personal and professional > interest in a topic to devote actual time and effort to attempting to cut > through the hype that mostly well-meaning but less-than-objective and > largely-uncritical supporters are shoveling out? Sheesh. > > ... > > >> Yes, every point you've made could be refuted. >> > > Rather than drool about it, try taking an actual shot at doing so: though > I'd normally consider talking with you to be a waste of my time, I'll make an > exception in this case. Call it a grudge match, if you want: I *really* > don't like the kind of incompetence that someone who behaves as you just did > represents and also consider it something in the nature of a civic duty to > expose if for what it is. > > ... > > >> I suggest getting a blog and ranting there, you have >> no audience here. >> > > Another demonstrably incorrect statement, I'm afraid: the contents of this > thread make it clear that some people here, despite their preconceptions, do > consider a detailed analysis of ZFS's relative strengths to be a fit subject > for discussion. And since it's only human for them to resist changing those > preconceptions, it's hardly surprising that the discussion gets slightly > heated at times. > > Education frequently can only occur through confrontation: existing biases > make it difficult for milder forms to get through. I'd like to help people > here learn something, but I'm at least equally interested in learning things > myself - and since there are areas in which I consider ZFS's design to be > significantly sub-optimal, where better to test that opinion than here? > > Unfortunately, so far the discussion has largely bogged down in debate over > just how important ZFS's unique (save for WAFL) checksum protection > mechanisms may be, and has not been very productive given the reluctance of > many here to tackle that question quantitatively (though David eventually > started to do so) - so there's been very little opportunity for learning on > my part save for a few details about media-file internals. I'm more > interested in discussing things like whether my suggested fix for RAID-Z's > poor parallel-small-access performance overlooked some real obstacle, or why > ZFS was presented as a highly-scalable file system when its largest files can > require up to 6 levels of indirect blocks (making performance for > random-access operations suck and causing snapshot data for updated large > files to balloon) and it offers no obvious extension path to clustered > operation (a single node - especially a single *commodity* node of the type > that ZFS otherwise favors - runs o > ut of steam in the PB range, or even lower for some workloads, and even > breaking control out into a separate metadata server doesn't get you that > much farther), or whether ZFS's apparently-centralized block-allocation > mechanisms can scale well (using preallocation to predistribute large chunks > that can be managed independently helps, but again doesn't get you beyond the > PB range at best), or the blind spot that some of the developers appear to > have about the importance of on-disk contiguity for streaming access > performance (128 KB chunks just don't cut it in terms of efficient disk > utilization in parallel environments unless they're grouped together), or its > trade-off of run-time performance and space use for performance when > accessing snapshots (I'm guessing that it was more faith in the virtue of > full-tree-path updating as compared with using a transaction log that > actually caused that decision, so perhaps that's the real subject for > discussion). > > Of course, given that ZFS is what it is, there's natural tendency just to > plow forward and not 'waste time' revisiting already-made decisions - so the > people best able to discuss them may not want to. But you never know unless > you try. > > - bill > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
