> Monday, December 10, 2007, 3:35:27 AM, you wrote: > > cyg> and it >>> made them slower > > cyg> That's the second time you've claimed that, so you'll really at > cyg> least have to describe *how* you measured this even if the > cyg> detailed results of those measurements may be lost in the mists of time. > > > cyg> So far you don't really have much of a position to defend at > cyg> all: rather, you sound like a lot of the disgruntled TOPS users > cyg> of that era. Not that they didn't have good reasons to feel > cyg> disgruntled - but they frequently weren't very careful about aiming > their ire accurately. > > cyg> Given that RMS really was *capable* of coming very close to the > cyg> performance capabilities of the underlying hardware, your > cyg> allegations just don't ring true. Not being able to jump into > > And where is your "proof" that it "was capable of coming very close to > the..."?
It's simple: I *know* it, because I worked *with*, and *on*, it - for many years. So when some bozo who worked with people with a major known chip on their shoulder over two decades ago comes along and knocks its capabilities, asking for specifics (not even hard evidence, just specific allegations which could be evaluated and if appropriate confronted) is hardly unreasonable. Hell, *I* gave more specific reasons why someone might dislike RMS in particular and VMS in general (complex and therefore user-unfriendly low-level interfaces and sometimes poor *default* performance) than David did: they just didn't happen to match those that he pulled out of (whereever) and that I challenged. > Let me use your own words: > > "In other words, you've got nothing, but you'd like people to believe it's > something. > > The phrase "Put up or shut up" comes to mind." > > Where are your proofs on some of your claims about ZFS? Well, aside from the fact that anyone with even half a clue knows what the effects of uncontrolled file fragmentation are on sequential access performance (and can even estimate those effects within moderately small error bounds if they know what the disk characteristics are and how bad the fragmentation is), if you're looking for additional evidence that even someone otherwise totally ignorant could appreciate there's the fact that Unix has for over two decades been constantly moving in the direction of less file fragmentation on disk - starting with the efforts that FFS made to at least increase proximity and begin to remedy the complete disregard for contiguity that the early Unix file system displayed and to which ZFS has apparently regressed, through the additional modifications that Kleiman and McVoy introduced in the early '90s to group 56 KB of blocks adjacently when possible, through the extent-based architectures of VxFS, XFS, JFS, and soon-to-be ext4 file systems ( I'm probably missing others here): given the relative changes between disk access times and bandwidth over the past decade and a half, ZFS with its max 128 KB blocks in splendid isolation offers significantly worse sequential performance relative to what's attainable than the systems that used 56 KB aggregates back then did (and they weren't all that great in that respect). Given how slow Unix was to understand and start to deal with this issue, perhaps it's not surprising how ignorant some Unix people still are - despite the fact that other platforms fully understood the problem over three decades ago. Last I knew, ZFS was still claiming that it needed nothing like defragmentation, while describing write allocation mechanisms that could allow disastrous degrees of fragmentation under conditions that I've described quite clearly. If ZFS made no efforts whatsoever in this respect the potential for unacceptable performance would probably already have been obvious even to its blindest supporters, so I suspect that when ZFS is given the opportunity by a sequentially-writing application that doesn't force every write (or by use of the ZIL in some cases) it aggregates blocks in a file together in cache and destages them in one contiguous chunk to disk (rather than just mixing blocks willy-nilly in its batch disk writes) - and a lot of the time there's probably not enough other system write activity to make this infeasible, so that people haven't found sequential streaming performance to be all that bad most of the time (especially on the read end if their systems are lightly load ed and the fact that their disks may be working a lot harder than they ought to have to is not a problem). But the potential remains for severe fragmention under heavily parallel access conditions, or when a file is updated at fine grain but then read sequentially (the whole basis of the recent database thread), and with that fragmentation comes commensurate performance degradation. And even if you're not capable of understanding why yourself you should consider it significant that no one on the ZFS development team has piped up to say otherwise. Then there's RAID-Z, which smears individual blocks across multiple disks in a manner that makes small-to-medium random access throughput suck. Again, this is simple logic and physics: if you understand the layout and the disk characteristics, you can predict the effects on a heavily parallel workload with fairly decent accuracy (I think that Roch mentioned this casually at one point, so it's hardly controversial, and I remember reading a comment by Jeff Bonwick that he was pleased with the result of one benchmark - which made no effort to demonstrate the worst case - because the throughput penalty was 'only' a factor of 2 rather than the full factor of N). And the way ZFS aparently dropped the ball on its alleged elimination of any kind of 'volume management' by requiring that users create explicit (and matched) aggregations of disks to support mirroring and RAID-Z. I'm not the only one here who has observed that handling data redundancy more in the manner of ditto blocks would not only improve transparency in this area but be more consistent with the rest of ZFS's approach to disk placement. Now, if someone came up with any kind of credible rebuttal to these assertions we could at least discuss it on technical grounds. But (and again you should consider this significant) no one has: all we have is well-reasoned analysis on the one hand and some (often fairly obnoxious) fanboy babble on the other. If you step back, make the effort required to *understand* that analysis, and try to look at the situation objectively, which do you find more credible? ZFS has other deficiencies, but they're more fundamental choices involving poor trade-offs and lack of vision than outright (and easily rectifiable) flaws, so they could more justifiably be termed 'judgment calls' and I haven't delved as deeply into them. But they're the main reason I have no interest in 'working on' ZFS: while it would be a quantitative exaggeration to characterize doing so as 'putting lipstick on a pig' (ZFS isn't a real pig - just one more decent but limited file system among many, based on a couple of good but hardly original ideas - COW and transparently-managed space pools - applied sub-optimally in its implementation), that metaphor qualitatively captures the sense of my feelings toward it. > Where are your detailed concepts how to solve some ZFS issues > (imagined or not)? Right here in this thread and in the database thread. I described how to reorganize opportunistically to limit fragmentation performance penalties (in a way that would not require any change in the on-disk structure) and how to replace RAID-Z with a RAID-5-like implementation to fix the throughput problem (though that would require extensions to ZFS's metadata pointer format). Perhaps it would behoove you to get up to speed before presuming to comment (though that doesn't seem to be very traditional in this community, so you might wind up feeling out of place). > > Demand nothing less from yourself than you demand from others. I do. And I seldom disappoint myself in that respect. > > Bill, to be honest I don't understand you Or most of what I've said, by all appearances. - you wrote "I have no > interest in working on it myself". So what is your interest here? You really haven't bothered to read much at all, have you. I've said, multiple times, that I came here initially in the hope of learning something interesting. More recently, I came here because I offered a more balanced assessment of ZFS's strengths and weaknesses in responding to the Yager article and wanted to be sure that I had not treated ZFS unfairly in some way - which started this extended interchange. After that, I explained that while the likelihood of learning anything technical here was looking pretty poor, I didn't particularly like some of the personal attacks that I'd been subject to and had decided to confront them. > The way you respond to people is offensive some times (don't bother to > say that they deserve it... it's just your opinion) Yes, it is - and that fully explains my behavior in that regard. Whether you agree with my assessment (or the appropriateness of my response) is not of significant interest to me. and your attitude > from time to time is of a "guru" who knows everything but doesn't > actually deliver anything. No, my attitude is that people too stupid and/or too lazy to understand what I *have* been delivering don't deserve much respect if they complain. > > So, except that you "fighting" ZFS everywhere you can, It's hardly a pervasive effort: I only take ZFS on when I happen to encounter fanboys who need straightening out. The first such was Robin Harris at his StoragaMojo and ZDNet blogs (which I occasionally visit), which led me to the controversy on the Hitz and Schwartz blogs and the Yager article, my response to which brought me back here. Had Jonathan not actively offended my sense of propriety by lying about what had initiated the patent skirmish and then cynically attempting to enlist the open source movement in what was a purely inter-corporate squabble I'd probably not have spent as much time and effort as I have. But that kind of high-level corporate sleaziness *really* disgusts me: I spent over 5 years playing truth-squad against Itanic to make sure that Compaq/HP paid a price for the way they screwed and lied to Alpha customers (and combined with the efforts of other like-minded people we actually succeeded pretty well, almost certainly costing them billions of dollars in profit given that Alpha systems provided a high-margin $7 billion annual revenue stream before the Alphacide and that most customers seemed inclined to follow along like sheep afterward until we shoved the pile so closely under their noses that they couldn't help noticing the stench), so what I've been doing with ZFS is really small potatoes by comparison. you don't want > to contribute to ZFS I just have no interest in *working* on it: if I were actively avoiding contributing at all, I wouldn't have explained what some of its problems are and how to correct them. > - what you want then? My answers above should have made that clear by now (not that they include any information in that regard that I haven't already presented before here, but now you've got the Readers Digest Condensed Version as well). - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
