On Tue, 11 Dec 2007, Robert Milkowski wrote: > Hello can, > > Tuesday, December 11, 2007, 6:57:43 PM, you wrote: > >>> 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..."? > > cyg> It's simple: I *know* it, because I worked *with*, and *on*, it > cyg> - for many years. So when some bozo who worked with people with > cyg> a major known chip on their shoulder over two decades ago comes > cyg> along and knocks its capabilities, asking for specifics (not even > cyg> hard evidence, just specific allegations which could be evaluated > cyg> and if appropriate confronted) is hardly unreasonable. > > Bill, you openly criticize people (their work) who have worked on ZFS > for years... not that there's anything wrong with that, just please > realize that because you were working on it it doesn't mean it is/was > perfect - just the same as with ZFS. > I know, everyone loves their baby... > > Nevertheless just because you were working on and with it, it's not a > proof. The person you were replaying to was also working with it (but > not on it I guess). Not that I'm interested in such a proof. Just > noticed that you're demanding some proof, while you are also just > write some statements on its performance without any actual proof. > > > >>> 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? > > cyg> Well, aside from the fact that anyone with even half a clue > cyg> knows what the effects of uncontrolled file fragmentation are on > cyg> sequential access performance (and can even estimate those > cyg> effects within moderately small error bounds if they know what > cyg> the disk characteristics are and how bad the fragmentation is), > cyg> if you're looking for additional evidence that even someone > cyg> otherwise totally ignorant could appreciate there's the fact that > > I've never said there are not fragmentation problems with ZFS. > Well, actually I've been hit by the issue in one environment. > Also you haven't done your work home properly, as one of ZFS > developers actually stated they are going to work on ZFS > de-fragmentation and disk removal (pool shrinking). > See http://www.opensolaris.org/jive/thread.jspa?messageID=139680𢆠 > Lukasz happens to be my friend who is also working with the same > environment. > > The point is, and you as a long time developer (I guess) should know it, > you can't have everything done at once (lack of resources, and it takes > some time anyway) so you must prioritize. ZFS is open source and if > someone thinks that given feature is more important than the other > he/she should try to fix it or at least voice it here so ZFS > developers can possibly adjust their priorities if there's good enough > and justified demand. > > Now the important part - quite a lot of people are using ZFS, from > desktop usage, their laptops, small to big production environments, > clustered environments, SAN environemnts, JBODs, entry-level to high-end > arrays, > different applications, workloads, etc. And somehow you can't find > many complaints about ZFS fragmentation. It doesn't mean the problem > doesn't exist (and I know it first hand) - it means that for whatever > reason for most people using ZFS it's not a big problem if problem at > all. However they do have other issues and many of them were already > addressed or are being addressed. I would say that ZFS developers at > least try to listen to the community. > > Why am I asking for a proof - well, given constrains on resources, I > would say we (not that I'm ZFS developer) should focus on actual > problems people have with ZFS rather then theoretical problems (which > in some environments/workloads will show up and sooner or later they > will have to be addressed too). > > Then you find people like Pawel Jakub Davidek (guy who ported ZFS to > FreeBSD) who started experimenting with RAID-5 like implementation > with ZFS - he provided even some numbers showing it might be worth > looking at. That's what community is about. > > I don't see any point complaining about ZFS all over again - have you > actually run into the problem with ZFS yourself? I guess not. You just > assuming (correctly for some usage cases). I guess your message has > been well heard. Since you're not interested in anything more that > bashing or complaining all the time about the same theoretical "issues" rather > than contributing somehow (even by providing some test results which > could be repeated) I wouldn't wait for any positive feedback if I were > you - anyway, what kind of feedback are you waiting for? > > > cyg> Last I knew, ZFS was still claiming that it needed nothing like > cyg> defragmentation, while describing write allocation mechanisms > cyg> that could allow disastrous degrees of fragmentation under > cyg> conditions that I've described quite clearly. > > Well, I haven't talked to ZFS (yet) so I don't know what he claims :)) > If you are talking about ZFS developers then you can actually find > some evidence that they do see that problem and want to work on it. > Again see for example: > http://www.opensolaris.org/jive/thread.jspa?messageID=139680𢆠 > Bill, at least look at the list archives first. > > And again, "under conditions that I've described quite clearly." - > that's exactly the problem. You've just described something while > others do have actual and real problems which should be addressed > first. > > > cyg> If ZFS made no > cyg> efforts whatsoever in this respect the potential for unacceptable > cyg> performance would probably already have been obvious even to its > cyg> blindest supporters, > > Well, is it really so hard to understand that a lot of people use ZFS > because it actually solves their problems? No matter what case > scenarios you will find to theoretically show some ZFS weaker points, > at the end what matters is if it does solve customer problems. And for > many users it does, definitely not for all of them. > I would argue that no matter what file system you will test or even > design, one can always find a corner cases when it will behave less > than optimal. For a general purpose file system what matters is that > in most common cases it's good enough. > > > cyg> willy-nilly in its batch disk writes) - and a lot of the time > cyg> there's probably not enough other system write activity to make > cyg> this infeasible, so that people haven't found sequential > cyg> streaming performance to be all that bad most of the time > cyg> (especially on the read end if their systems are lightly load > cyg> ed and the fact that their disks may be working a lot harder > cyg> than they ought to have to is not a problem). > > Now you closer to the point. If the problem you are describing does > not hit most people, we should put more effort solving problems which > people are actually experiencing. > > > cyg> Then there's RAID-Z, which smears individual blocks across > cyg> multiple disks in a manner that makes small-to-medium random > cyg> access throughput suck. Again, this is simple logic and physics: > cyg> if you understand the layout and the disk characteristics, you > cyg> can predict the effects on a heavily parallel workload with > cyg> fairly decent accuracy (I think that Roch mentioned this casually > cyg> at one point, so it's hardly controversial, and I remember > cyg> reading a comment by Jeff Bonwick that he was pleased with the > cyg> result of one benchmark - which made no effort to demonstrate the > cyg> worst case - because the throughput penalty was 'only' a factor > cyg> of 2 rather than the full factor of N). > > Yeah, nothing really new here. If you need a guy from Sun, then read > Roch's post on RAID-Z performance. Nothing you've discovered here. > Nevertheless RAID-Z[2] is good enough for many people. > I know that simple logic and physics states that relativity equations > provide better accuracy than Newton's - nevertheless in most scenarios > I'm dealing with it doesn't really matter from a practical point of > view. > > Then, in some environments RAID-Z2 (on JBOD) actually provides better > performance than RAID-5 (and HW R5 for that matter). And, opposite > to you, I'm not speculating but I've been working with such > environment (lot of concurrent writes which are more critical than > much less reads later). > So when you saying that RAID-Z is brain-damaging - well, it's > mostly positive experience of a lot of people with RAID-Z vs. your statement > without any > real-world backing. > > Then, of course, one can produce a test or even real work environment > where there will be lot of small and simultaneous reads, without any > writes, from a dataset much bigger than available memory and RAID-Z would be > much slower than > RAID-5. Not that it's novel - it was well discussed since RAID-Z was > introduced. That's one of the reasons why people use ZFS on-top of > HW RAID-5 luns from time to time. > > > cyg> And the way ZFS aparently dropped the ball on its alleged > cyg> elimination of any kind of 'volume management' by requiring that > cyg> users create explicit (and matched) aggregations of disks to > cyg> support mirroring and RAID-Z. > > # mkfile 128m f1 ; mkfile 128m f2 ; mkfile 256m f3 ; mkfile 256m f4 > # zpool create bill mirror /var/tmp/f1 /var/tmp/f2 mirror /var/tmp/f3 > /var/tmp/f4 > # zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > bill 373M 90K 373M 0% ONLINE - > # > # mkfile 128m f11 ; mkfile 256m f44 > # zpool destroy bill > # zpool create bill raidz /var/tmp/f11 /var/tmp/f1 /var/tmp/f2 raidz > /var/tmp/f3 /var/tmp/f4 /var/tmp/f44 > # zfs list > NAME USED AVAIL REFER MOUNTPOINT > bill 101K 715M 32.6K /bill > # > (2*128+2*256=768) - looks fine. > > If you are talking about a solution which enables user to mix > different disk sizes in the same mirror or RAID-5 group and while all > the time providing given protection allows you to utilize 100% of all > disk capacities.... well, what is that solution? Is it free? > Open source? Available on general purpose OS? Or commodity HW? > Available at all? :P > > > cyg> Now, if someone came up with any kind of credible rebuttal to > cyg> these assertions we could at least discuss it on technical > cyg> grounds. But (and again you should consider this significant) no > cyg> one has: all we have is well-reasoned analysis on the one hand > cyg> and some (often fairly obnoxious) fanboy babble on the other. If > cyg> you step back, make the effort required to *understand* that > cyg> analysis, and try to look at the situation objectively, which do you > find more credible? > > Most credible to me is actual user experience than some theoretical > burbling. While I appreciate it, and to some extend it's valid, for me > again most important is actual experience. Going endlessly all over > again, why ZFS is bad because you think fragmentation is a big issue, > while most of the actual users don't agree, is pointless imho. > > Instead, try to do something positive and practical - for all the time > you spend on bashing ZFS, you probably would have already come up with > some basic proof-of-concept of flawless RAID-5 in ZFS or > fragmentation-free improvement, and once you've proved it actually is > promising everyone would love you and help you polishing the code. > > :))))))) > > > cyg> ZFS has other deficiencies, but they're more fundamental choices > cyg> involving poor trade-offs and lack of vision than outright (and > cyg> easily rectifiable) flaws, so they could more justifiably be > cyg> termed 'judgment calls' and I haven't delved as deeply into them. > > And what they are? What are the alternatives in a market? > Whie ZFS is not perfect, and for some people lack of user quotes is > no-go with ZFS, for many other it just doesn't make sense to go with > NetApp if only for economical reasons. > > Whatever theoretical deficiencies you have in mind, I myself, and many > others, when confronted with ZFS in real world environments, I find it > most of the time much more flexible in managing storage than LVM, XFS, > UFS, VxVM/VxVF, NetApp. Also more secure, etc. And quite often similar > with similar performance or even better. Then thanks to zfs send|recv > I get really interesting backup option. > > What some people are also looking for, I guess, is a black-box > approach - easy to use GUI on top of Solaris/ZFS/iSCSI/etc. So they > don't have to even know it's ZFS or Solaris. Well... > > > cyg> But they're the main reason I have no interest in 'working on' > > Well, you're not using ZFS, you are not interested in working on it, > all you are interested is finding some potential corner cases bad for > ZFS and bashing it. If you put at least 10% of your energy you're > putting in your 'holy war' you would at least provide some benchmarks > (filebench?) showing these corner cases in comparison to other > mind-blowing solutions on the market which are much better than ZFS, > so we can all reproduce them and try to address ZFS problems. > > :)))) > > > [...] >>> And I seldom disappoint myself in that respect. > > Honestly, I believe you - no doubt about it. > > > cyg> You really haven't bothered to read much at all, have you. I've > cyg> said, multiple times, that I came here initially in the hope of > cyg> learning something interesting. More recently, I came here > cyg> because I offered a more balanced assessment of ZFS's strengths > cyg> and weaknesses in responding to the Yager article and wanted to > cyg> be sure that I had not treated ZFS unfairly in some way - which > cyg> started this extended interchange. After that, I explained that > cyg> while the likelihood of learning anything technical here was > cyg> looking pretty poor, I didn't particularly like some of the > cyg> personal attacks that I'd been subject to and had decided to confront > them. > > Well, every time I saw it was you 'attacking' other people first. > And it's just your opinion that you offered more balanced assessment > which is not shared by many. > > If you are not contributing here, and you are not learning here - wy > are you here? I'm serious - why? > Wouldn't it better serve you to actually contribute to the other > project, where developers actually get it - where no one is personally > attacking you, where there are no fundamental bad choices made while > in design, where RAID-5 is flawless, fragmentation problem doesn't > exist neither all the other corner cases. Performance is best in a > market all the time, and I can run in on commodity HW or so called big > iron, on a well known general purpose OS. Well, I assume that project > is open source too - maybe you share with all of us that secret so we can > join it too and forget about ZFS? I'm first to "convert" and forget > about ZFS. Of course as that secret project is so perfect it probably > doesn't make sense to contribute as developer as there is nothing left > to contribute - but, hey - I'm not a developer - I'm user and I'm > definitely interested in that project. > > cyg> No, my attitude is that people too stupid and/or too lazy to > cyg> understand what I *have* been delivering don't deserve much respect if > they complain. > > Maybe you should thing about that "stupid" part... > Maybe, just maybe, it's possible that all people around you don't > understand you, that world is wrong and we're all so stupid. Well, > maybe. Even if it is so, then perhaps it's time to stop being Don Quixote > and move on? >
+1 Well said Robert! 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