> 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
