Re: [zfs-discuss] Yager on ZFS
Hello can, Thursday, December 13, 2007, 12:02:56 AM, you wrote: cyg On the other hand, there's always the possibility that someone cyg else learned something useful out of this. And my question about To be honest - there's basically nothing useful in the thread, perhaps except one thing - doesn't make any sense to listen to you. You're just unable to talk to people. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
People.. for the n-teenth time, there are only two ways to kill a troll. One involves a woodchipper and the possibility of an unwelcome visit from the FBI, and the other involves ignoring them. Internet Trolls: http://en.wikipedia.org/wiki/Internet_troll http://www.linuxextremist.com/?p=34 Another perspective: http://sc.tri-bit.com/images/7/7e/greaterinternetfu#kwadtheory.jpg The irony of this whole thing is that by feeding Bill's tollish tendencies, he has effectively eliminated himself from any job or contract where someone googles his name and thus will give him an enormous amount of time to troll forums. Who in their right mind would consciously hire someone who calls people idiots randomly to avoid the topic at hand. Being unemployed will just piss him off more and his trolling will only get worse. Hence, you don't feed trolls!! This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Hello can, Thursday, December 13, 2007, 12:02:56 AM, you wrote: cyg On the other hand, there's always the possibility that someone cyg else learned something useful out of this. And my question about To be honest - there's basically nothing useful in the thread, perhaps except one thing - doesn't make any sense to listen to you. I'm afraid you don't qualify to have an opinion on that, Robert - because you so obviously *haven't* really listened. Until it became obvious that you never would, I was willing to continue to attempt to carry on a technical discussion with you, while ignoring the morons here who had nothing whatsoever in the way of technical comments to offer (but continued to babble on anyway). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Would you two please SHUT THE F$%K UP. Dear God, my kids don't go own like this. Please - let it die already. Thanks very much. /jim can you guess? wrote: Hello can, Thursday, December 13, 2007, 12:02:56 AM, you wrote: cyg On the other hand, there's always the possibility that someone cyg else learned something useful out of this. And my question about To be honest - there's basically nothing useful in the thread, perhaps except one thing - doesn't make any sense to listen to you. I'm afraid you don't qualify to have an opinion on that, Robert - because you so obviously *haven't* really listened. Until it became obvious that you never would, I was willing to continue to attempt to carry on a technical discussion with you, while ignoring the morons here who had nothing whatsoever in the way of technical comments to offer (but continued to babble on anyway). - 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
Re: [zfs-discuss] Yager on ZFS
Would you two please SHUT THE F$%K UP. Just for future reference, if you're attempting to squelch a public conversation it's often more effective to use private email to do it rather than contribute to the continuance of that public conversation yourself. Have a nice day! - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
(apologies if this gets posted twice - it disappeared the first time, and it's not clear whether that was intentional) 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. Of course it doesn't - and I never claimed that RMS was anything close to 'perfect' (I even gave specific examples of areas in which it was *far* from perfect). Just as I've given specific examples of where ZFS is far from perfect. What I challenged was David's assertion that RMS was severely deficient in its *capabilities* - and demanded not 'proof' of any kind but only specific examples (comparable in specificity to the examples of ZFS's deficiencies that *I* have provided) that could actually be discussed. I know, everyone loves their baby... No, you don't know: you just assume that everyone is as biased as you and others here seem to be. 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. You really ought to spend a lot more time understanding what you've read before responding to it, Robert. I *never* asked for anything like 'proof': I asked for *examples* specific enough to address - and repeated that explicitly in responding to your previous demand for 'proof'. Perhaps I should at that time have observed that your demand for 'proof' (your use of quotes suggesting that it was something that *I* had demanded) was ridiculous, but I thought my response made that obvious. 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. Not having made a study of your collected ZFS contributions here I didn't know that. But some of ZFS's developers are on record stating that they believe there is no need to defragment (unless they've changed their views since and not bothered to make us aware of it), and in the entire discussion in the recent 'ZFS + DB + fragments' thread there were only three contributors (Roch, Anton, and I) who seemed willing to admit that any problem existed. So since one of my 'claims' for which you requested substantiation involved fragmentation problems, it seemed appropriate to address them. Well, actually I've been hit by the issue in one environment. But didn't feel any impulse to mention that during all the preceding discussion, I guess. 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
Re: [zfs-discuss] Yager on ZFS
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. Of course it doesn't - and I never claimed that RMS was anything close to 'perfect' (I even gave specific examples of areas in which it was *far* from perfect). Just as I've given specific examples of where ZFS is far from perfect. What I challenged was David's assertion that RMS was severely deficient in its *capabilities* - and demanded not 'proof' of any kind but only specific examples (comparable in specificity to the examples of ZFS's deficiencies that *I* have provided) that could actually be discussed. I know, everyone loves their baby... No, you don't know: you just assume that everyone is as biased as you and others here seem to be. 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. You really ought to spend a lot more time understanding what you've read before responding to it, Robert. I *never* asked for anything like 'proof': I asked for *examples* specific enough to address - and repeated that explicitly in responding to your previous demand for 'proof'. Perhaps I should at that time have observed that your demand for 'proof' (your use of quotes suggesting that it was something that *I* had demanded) was ridiculous, but I thought my response made that obvious. 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. Not having made a study of your collected ZFS contributions here I didn't know that. But some of ZFS's developers are on record stating that they believe there is no need to defragment (unless they've changed their views since and not bothered to make us aware of it), and in the entire discussion in the recent 'ZFS + DB + fragments' thread there were only three contributors (Roch, Anton, and I) who seemed willing to admit that any problem existed. So since one of my 'claims' for which you requested substantiation involved fragmentation problems, it seemed appropriate to address them. Well, actually I've been hit by the issue in one environment. But didn't feel any impulse to mention that during all the preceding discussion, I guess. 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↠ Hmmm - there were at least two Sun ZFS personnel participating in the database thread, and they never mentioned
Re: [zfs-discuss] Yager on ZFS
Hello can, I haven't been wasting so much time as in this thread... but from time to time it won't hurt :) More below :) Wednesday, December 12, 2007, 4:46:42 PM, you wrote: Hello Bill, I know, everyone loves their baby... cyg No, you don't know: you just assume that everyone is as biased cyg as you and others here seem to be. Which in turn is just your assumption :) I've never said there are not fragmentation problems with ZFS. cyg Not having made a study of your collected ZFS contributions here cyg I didn't know that. But some of ZFS's developers are on record cyg stating that they believe there is no need to defragment (unless cyg they've changed their views since and not bothered to make us cyg aware of it), and in the entire discussion in the recent 'ZFS + cyg DB + fragments' thread there were only three contributors cyg (Roch, Anton, and I) who seemed willing to admit that any problem existed. Which ZFS developer said that there's no need to defragment in ZFS? cyg So since one of my 'claims' for which you requested cyg substantiation involved fragmentation problems, it seemed appropriate to address them. I would say that right now there are other more important things to be done in ZFS than addressing fragmentation. While in one environment it looks like lowering fragmentation would help with some issues, in all the other environments I haven't run into fragmentation problem. 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? cyg Hmmm - there were at least two Sun ZFS personnel participating cyg in the database thread, and they never mentioned this. I guess cyg they didn't do their 'work home' properly either (and unlike me they're paid to do it). Maybe they don't know? Different project, different group? My understanding (I might be wrong) is that actually what they are working on is disk removal from pool (which looks like is much more requested by people than fixing fragmentation 'problem'). In order to accomplish it you need a mechanism to re-arrange data in a pool, which as a side effect could be also used as a de-fragment tool. That doesn't mean the pool won't fragment again in a future - if it's a real problem in given 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. cyg The issues here are not issues of prioritization but issues of cyg denial. Your citation above is the first suggestion that I've cyg seen (and by all appearances the first that anyone else cyg participating in these discussions has seen) that the ZFS crew cyg considers the fragmentation issue important enough to merit active attention in the future. Jeeez... now you need some kind of acknowledge from ZFS developers every time you think you found something? Are you paying their bills or what? While it's fine to talk about theoretical/hypothetical problems, I'm not entirely sure here is a good place to do it. On the other hand you can very often find ZFS developers responding on this list (and not only) to actual user problems. Another problem, I guess, could be - they already spent a lot of their time in projects they have to deliver - do you really expect them to spent still more time on analyzing some loosely statements of yours? Come on, they also have their private lifes and other things to do. Ignoring their customers/users would be unwise, responding to everyone with every problem, especially not a real user experience problem - would be just unpractical. Then there is your attitude - you know, there's a very good reasons why people at interviews are checking if you can actually work with the others people in a group. You're a very good example why. Don't expect people to take you seriously if you behave the way you do. As you put it before - you get what you deserve for. You probably got even more attention here that you deserved. I guess, that you are another good engineer, quite skillful, unfortunately unable to work in a team, and definitely not with customers. I would say some people here recognized it within you and did their best to treat you seriously and actually hear you - it's just that everyone has his limits. Looking thru your posts here, you can find lots words, some technical input but not much actual value - at first it could be entertaining, even intriguing but quickly becomes irritating. Bill, you could be the best engineer in the world, if you can't communicate with it you'll be the only one person who would recognize it. Or perhaps some people here (not only here) are right and for whatever reasons you are just trolling. cyg Do you by any chance have any similar hint of recognition that cyg RAID-Z might benefit from
Re: [zfs-discuss] Yager on ZFS
... Bill - I don't think there's a point in continuing that discussion. I think you've finally found something upon which we can agree. I still haven't figured out exactly where on the stupid/intellectually dishonest spectrum you fall (lazy is probably out: you have put some effort in to responding), but it is clear that you're hopeless. On the other hand, there's always the possibility that someone else learned something useful out of this. And my question about just how committed you were to your ignorance has been answered. It's difficult to imagine how someone so incompetent in the specific area that he's debating can be so self-assured - I suspect that just not listening has a lot to do with it - but also kind of interesting to see that in action. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Look, it's obvious this guy talks about himself as if he is the person he is addressing. Please stop taking this personally and feeding the troll. can you guess? wrote: Bill - I don't think there's a point in continuing that discussion. I think you've finally found something upon which we can agree. I still haven't figured out exactly where on the stupid/intellectually dishonest spectrum you fall (lazy is probably out: you have put some effort in to responding), but it is clear that you're hopeless. On the other hand, there's always the possibility that someone else learned something useful out of this. And my question about just how committed you were to your ignorance has been answered. It's difficult to imagine how someone so incompetent in the specific area that he's debating can be so self-assured - I suspect that just not listening has a lot to do with it - but also kind of interesting to see that in action. - bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
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
Re: [zfs-discuss] Yager on ZFS
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#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
Re: [zfs-discuss] Yager on ZFS
On 11-Dec-07, at 9:44 PM, Robert Milkowski wrote: Hello can, ... 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... Pretty soon OS X will be exactly that - a native booting zero-admin ZFS-based system - as used by your grandmother on her iMac, your kid son on his iBook, etc ... 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. And don't forget - the perfect system doesn't waste time checksumming! It's unnecessary! 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? ... perhaps it's time to stop being Don Quixote and move on? At least Sr Quixote was funny and never rude without provocation. --Toby -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ 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
Re: [zfs-discuss] Yager on ZFS
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#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
Re: [zfs-discuss] Yager on ZFS
Hello can, 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...? 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? Where are your detailed concepts how to solve some ZFS issues (imagined or not)? Demand nothing less from yourself than you demand from others. Bill, to be honest I don't understand you - you wrote I have no interest in working on it myself. So what is your interest here? The way you respond to people is offensive some times (don't bother to say that they deserve it... it's just your opinion) and your attitude from time to time is of a guru who knows everything but doesn't actually deliver anything. So, except that you fighting ZFS everywhere you can, you don't want to contribute to ZFS - what you want then? You seem like a guy with a quite good technical background (just an impression) who wants to contribute something but doesn't know exactly what... Maybe you should try to focus that knowledge a little bit more and get something useful out of it instead of writing long essays which doesn't contribute much (not that this reply isn't long :)) I'm not being malicious here - I'm genuinely interested in what's your agenda. I don't blame other people accusing you of trolling. No offense intended. :) -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
grand-dad, why don't you put your immense experience and knowledge to contribute to what is going to be the next and only filesystems in modern operating systems, instead of spending your time asking for specifics and treating everyone of ignorant..at least we will remember you in the after life as being a major contributor to zfs success. Considering that you have never been considered by anyone until now (excpet your dog?)...who has ever heard of you ?? have you ever published anything worth reading? give us some of you mighty accomplishements. remember now it's about opensourcing, reducing complexity and cost...keep the old propriatery things in DEC's drawers and bring us real ideas s- On Dec 9, 2007 4:32 AM, can you guess? [EMAIL PROTECTED] wrote: can you run a database on RMS? As well as you could on must Unix file systems. And you've been able to do so for almost three decades now (whereas features like asynchronous and direct I/O are relative newcomers in the Unix environment). I guess its not suited And you guess wrong: that's what happens when you speak from ignorance rather than from something more substantial. we are already trying to get ride of a 15 years old filesystem called wafl, Whatever for? Please be specific about exactly what you expect will work better with whatever you're planning to replace it with - and why you expect it to be anywhere nearly as solid. and a 10 years old file system called Centera, My, you must have been one of the *very* early adopters, since EMC launched it only 5 1/2 years ago. so do you thing we are going to consider a 35 years old filesystem now... computer science made a lot of improvement since Well yes, and no. For example, most Unix platforms are still struggling to match the features which VMS clusters had over two decades ago: when you start as far behind as Unix did, even continual advances may still not be enough to match such 'old' technology. Not that anyone was suggesting that you replace your current environment with RMS: if it's your data, knock yourself out using whatever you feel like using. On the other hand, if someone else is entrusting you with *their* data, they might be better off looking for someone with more experience and sense. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- -- Blog: http://fakoli.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: can you guess? wrote: can you run a database on RMS? As well as you could on must Unix file systems. And you've been able to do so for almost three decades now (whereas features like asynchronous and direct I/O are relative newcomers in the Unix environment). nny, I remember trying to help customers move their applications from TOPS-20 to VMS, back in the early 1980s, and finding that the VMS I/O capabilities were really badly lacking. Funny how that works: when you're not familiar with something, you often mistake your own ignorance for actual deficiencies. Of course, the TOPS-20 crowd was extremely unhappy at being forced to migrate at all, and this hardly improved their perception of the situation. If you'd like to provide specifics about exactly what was supposedly lacking, it would be possible to evaluate the accuracy of your recollection. I've played this game before, and it's off-topic and too much work to be worth it. Researching exactly when specific features were released into VMS RMS from this distance would be a total pain, and then we'd argue about which ones were beneficial for which situations, which people didin't much agree about then or since. My experience at the time was that RMS was another layer of abstraction and performance loss between the application and the OS, and it made it harder to do things and it made them slower and it made files less interchangeable between applications; but I'm not interested in trying to defend this position for weeks based on 25-year-old memories. -- David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
... I remember trying to help customers move their applications from TOPS-20 to VMS, back in the early 1980s, and finding that the VMS I/O capabilities were really badly lacking. Funny how that works: when you're not familiar with something, you often mistake your own ignorance for actual deficiencies. Of course, the TOPS-20 crowd was extremely unhappy at being forced to migrate at all, and this hardly improved their perception of the situation. If you'd like to provide specifics about exactly what was supposedly lacking, it would be possible to evaluate the accuracy of your recollection. I've played this game before, and it's off-topic and too much work to be worth it. 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. Researching exactly when specific features were released into VMS RMS from this distance would be a total pain, I wasn't asking for anything like that: I was simply asking for specific examples of the VMS I/O capabilities that you allegedly 'found' were really badly lacking in the early 1980s. Even if the porting efforts you were involved in predated the pivotal cancellation of Jupiter in 1983, that was still close enough to the VMS cluster release that most VMS development effort had turned in that direction (i.e., the single-system VMS I/O subsystem had pretty well reached maturity), so there won't be any need to quibble about what shipped when. Surely if you had a sufficiently strong recollection to be willing to make such a definitive assertion you can remember *something* specific. and then we'd argue about which ones were beneficial for which situations, which people didin't much agree about then or since. No, no, no: you're reading far more generality into this than I ever suggested. I'm not asking you to judge what was useful, and I couldn't care less whether you thought the features that VMS had and TOPS lacked were valuable: I'm just asking you to be specific about what VMS I/O capabilities you claim were seriously deficient. My experience at the time was that RMS was another layer of abstraction and performance loss between the application and the OS, Ah - your 'experience'. So you actually measured RMS's effect on performance, rather than just SWAGged that adding a layer that you found unappealing in a product that your customers were angry about having to move to Must Be A Bad Idea? What was the quantitative result of that measurement, and how was RMS configured for the relevant workload? After all, the extra layer wasn't introduced just to give you something to complain about: it was there to provide additional features and configuration flexibility (much of it performance-related), as described above. If you didn't take advantage of those facilities, that could be a legitimate *complexity* knock against the environment but it's not a legitimate *capability* or *performance* knock (rather the opposite, in fact). and it made it harder to do things If you were using the RMS API itself rather than accessing RMS through a higher-level language that provided simple I/O handling for simple I/O needs, that was undoubtedly the case: as I observed above, that's a price that VMS was happy to pay for providing complete control to applications that wanted it. RMS was designed from the start to provide that alternative with the understanding that access via higher-level language mechanisms would usually be used by those people who didn't need the low-level control that the native RMS API provided. and it made them slower That's the second time you've claimed that, so you'll really at least have to describe *how* you measured this even if the detailed results of those measurements may be lost in the mists of time. and it made files less interchangeable between applications; That would have been some trick, given that RMS supported pure byte-stream files as well as its many more structured types (and I'm pretty sure that the C run-time system took this approach, using RMS direct I/O and doing its own deblocking to ensure that some of the more idiomatic C activities like single-character reads and writes would not inadvertently perform poorly). So at worst you could have used precisely the same in-file formats that were being used in the TOPS-20 environment and achieved the same degree of portability (unless you were actually encountering peculiarities in language access rather than in RMS itself: I'm considerably less familiar with that end of the environment). but I'm not interested in trying to defend this position for weeks based on 25-year-old memories. So far you don't really have much of a position to defend at all: rather, you sound like a lot of the disgruntled TOPS users of that era. Not that they didn't have good reasons to feel disgruntled - but
Re: [zfs-discuss] Yager on ZFS
why don't you put your immense experience and knowledge to contribute to what is going to be the next and only filesystems in modern operating systems, Ah - the pungent aroma of teenage fanboy wafts across the Net. ZFS is not nearly good enough to become what you suggest above, nor is it amenable to some of the changes necessary to make it good enough. So while I'm happy to give people who have some personal reason to care about it pointers on how it could be improved, I have no interest in working on it myself. instead of spending your time asking for specifics You'll really need to learn to pay a lot more attention to specifics yourself if you have any desire to become technically competent when you grow up. and treating everyone of ignorant I make some effort only to treat the ignorant as ignorant. It's hardly my fault that they are so common around here, but I'd like to think that there's a silent majority of more competent individuals in the forum who just look on quietly (and perhaps somewhat askance). It used to be that the ignorant felt motivated to improve themselves, but now they seem more inclined to engage in aggressive denial (which may be easier on the intellect but seems a less productive use of energy). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
from the description here http://www.djesys.com/vms/freevms/mentor/rms.html so who cares here ? RMS is not a filesystem, but more a CAS type of data repository Since David begins his description with the statement RMS stands for Record Management Services. It is the underlying file system of OpenVMS, I'll suggest that your citation fails a priori to support your allegation above. Perhaps you're confused by the fact that RMS/Files-11 is a great deal *more* of a file system than most Unix examples (though ReiserFS was at least heading in somewhat similar directions). You might also be confused by the fact that VMS separates its file system facilities into an underlying block storage and directory layer specific to disk storage and the upper RMS deblocking/interpretation/pan-device layer, whereas Unix combines the two. Better acquainting yourself with what CAS means in the context of contemporary disk storage solutions might be a good idea as well, since it bears no relation to RMS (nor to virtually any Unix file system). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
from the description here http://www.djesys.com/vms/freevms/mentor/rms.html so who cares here ? RMS is not a filesystem, but more a CAS type of data repository On Dec 8, 2007 7:04 AM, Anton B. Rang [EMAIL PROTECTED] wrote: NOTHING anton listed takes the place of ZFS That's not surprising, since I didn't list any file systems. Here's a few file systems, and some of their distinguishing features. None of them do exactly what ZFS does. ZFS doesn't do what they do, either. QFS: Very, very fast. Supports segregation of data from metadata, and classes of data. Supports SAN access to data. XFS: Also fast; works efficiently on multiprocessors (in part because allocation can proceed in parallel). Supports SAN access to data (CXFS). Delayed allocation allows temporary files to stay in memory and never even be written to disk (and improves contiguity of data on disk). JFS: Another very solid journaled file system. GPFS: Yet another SAN file system, with tighter semantics than QFS or XFS; highly reliable. StorNext: Hey, it's another SAN file system! Guaranteed I/O rates (hmmm, which XFS has too, at least on Irix) -- a key for video use. SAMFS: Integrated archiving -- got petabytes of data that you need virtually online? SAM's your man! (well, at least your file system) AdvFS: A journaled file system with snapshots, integrated volume management, online defragmentation, etc. VxFS: Everybody knows, right? Journaling, snapshots (including writable snapshots), highly tuned features for databases, block-level change tracking for more efficient backups, etc. There are many, many different needs. There's a reason why there is no one true file system. -- Anton Better yet, you get back to writing that file system that's going to fix all these horrible deficiencies in zfs. Ever heard of RMS? A file system which supports not only sequential access to files, or random access, but keyed access. (e.g. update the record whose key is 123)? A file system which allowed any program to read any file, without needing to know about its internal format? (so such an indexed file could just be read as a sequence of ordered records by applications which processed ordinary text files.) A file system which could be shared between two, or even more, running operating systems, with direct access from each system to the disks. A file system with features like access control with alarms, MAC security on a per-file basis, multiple file versions, automatic deletion of temporary files, verify-after-write. You probably wouldn't be interested; but others would. It solves a particular set of needs (primarily in the enterprise market). It did it very well. It did it some 30 years before ZFS. It's very much worthwhile listening to those who built such a system, and their experiences, if your goal is to learn about file systems. Even if they don't suffer fools gladly. If you've got a problem for which ZFS is the best solution, great. Use it. But don't think that it solves every problem, nor that it's perfect for everyone -- even you. (One particular area to think about -- how do you back up your multi-terabyte pool? And how do you restore an individual file from your backups?) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- -- Blog: http://fakoli.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you run a database on RMS? I guess its not suited we are already trying to get ride of a 15 years old filesystem called wafl, and a 10 years old file system called Centera, so do you thing we are going to consider a 35 years old filesystem now... computer science made a lot of improvement since On Dec 8, 2007 1:38 PM, can you guess? [EMAIL PROTECTED] wrote: from the description here http://www.djesys.com/vms/freevms/mentor/rms.html so who cares here ? RMS is not a filesystem, but more a CAS type of data repository Since David begins his description with the statement RMS stands for Record Management Services. It is the underlying file system of OpenVMS, I'll suggest that your citation fails a priori to support your allegation above. Perhaps you're confused by the fact that RMS/Files-11 is a great deal *more* of a file system than most Unix examples (though ReiserFS was at least heading in somewhat similar directions). You might also be confused by the fact that VMS separates its file system facilities into an underlying block storage and directory layer specific to disk storage and the upper RMS deblocking/interpretation/pan-device layer, whereas Unix combines the two. Better acquainting yourself with what CAS means in the context of contemporary disk storage solutions might be a good idea as well, since it bears no relation to RMS (nor to virtually any Unix file system). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- -- Blog: http://fakoli.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you run a database on RMS? As well as you could on must Unix file systems. And you've been able to do so for almost three decades now (whereas features like asynchronous and direct I/O are relative newcomers in the Unix environment). I guess its not suited And you guess wrong: that's what happens when you speak from ignorance rather than from something more substantial. we are already trying to get ride of a 15 years old filesystem called wafl, Whatever for? Please be specific about exactly what you expect will work better with whatever you're planning to replace it with - and why you expect it to be anywhere nearly as solid. and a 10 years old file system called Centera, My, you must have been one of the *very* early adopters, since EMC launched it only 5 1/2 years ago. so do you thing we are going to consider a 35 years old filesystem now... computer science made a lot of improvement since Well yes, and no. For example, most Unix platforms are still struggling to match the features which VMS clusters had over two decades ago: when you start as far behind as Unix did, even continual advances may still not be enough to match such 'old' technology. Not that anyone was suggesting that you replace your current environment with RMS: if it's your data, knock yourself out using whatever you feel like using. On the other hand, if someone else is entrusting you with *their* data, they might be better off looking for someone with more experience and sense. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: can you run a database on RMS? As well as you could on must Unix file systems. And you've been able to do so for almost three decades now (whereas features like asynchronous and direct I/O are relative newcomers in the Unix environment). Funny, I remember trying to help customers move their applications from TOPS-20 to VMS, back in the early 1980s, and finding that the VMS I/O capabilities were really badly lacking. RMS was an abomination -- nothing but trouble, and another layer to keep you away from your data. Of course, TOPS-20 isn't Unix; it's one of the things the original Unix developers couldn't afford, so they had to try to write something that would work for them and would run on hardware they *could* afford (the other one was Multics of course). -- David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: can you run a database on RMS? As well as you could on must Unix file systems. And you've been able to do so for almost three decades now (whereas features like asynchronous and direct I/O are relative newcomers in the Unix environment). nny, I remember trying to help customers move their applications from TOPS-20 to VMS, back in the early 1980s, and finding that the VMS I/O capabilities were really badly lacking. Funny how that works: when you're not familiar with something, you often mistake your own ignorance for actual deficiencies. Of course, the TOPS-20 crowd was extremely unhappy at being forced to migrate at all, and this hardly improved their perception of the situation. If you'd like to provide specifics about exactly what was supposedly lacking, it would be possible to evaluate the accuracy of your recollection. RMS was an abomination -- nothing but trouble, Again, specifics would allow an assessment of that opinion. and another layer to keep you away from your data. Real men use raw disks, of course. And with RMS (unlike Unix systems of that era) you could get very close to that point if you wanted to without abandoning the file level of abstraction - or work at a considerably more civilized level if you wanted that with minimal sacrifice in performance (again, unlike the Unix systems of that era, where storage performance was a joke until FFS began to improve things - slowly). VMS and RMS represented a very different philosophy than Unix: you could do anything, and therefore were exposed to the complexity that this flexibility entailed. Unix let you do things one simple way - whether it actually met your needs or not. Back then, efficient use of processing cycles (even in storage applications) could be important - and VMS and RMS gave you that option. Nowadays, trading off cycles to obtain simplicity is a lot more feasible, and the reasons for the complex interfaces of yesteryear can be difficult to remember. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
I believe the data dedup is also a feature of NTFS. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
NOTHING anton listed takes the place of ZFS That's not surprising, since I didn't list any file systems. Here's a few file systems, and some of their distinguishing features. None of them do exactly what ZFS does. ZFS doesn't do what they do, either. QFS: Very, very fast. Supports segregation of data from metadata, and classes of data. Supports SAN access to data. XFS: Also fast; works efficiently on multiprocessors (in part because allocation can proceed in parallel). Supports SAN access to data (CXFS). Delayed allocation allows temporary files to stay in memory and never even be written to disk (and improves contiguity of data on disk). JFS: Another very solid journaled file system. GPFS: Yet another SAN file system, with tighter semantics than QFS or XFS; highly reliable. StorNext: Hey, it's another SAN file system! Guaranteed I/O rates (hmmm, which XFS has too, at least on Irix) -- a key for video use. SAMFS: Integrated archiving -- got petabytes of data that you need virtually online? SAM's your man! (well, at least your file system) AdvFS: A journaled file system with snapshots, integrated volume management, online defragmentation, etc. VxFS: Everybody knows, right? Journaling, snapshots (including writable snapshots), highly tuned features for databases, block-level change tracking for more efficient backups, etc. There are many, many different needs. There's a reason why there is no one true file system. -- Anton Better yet, you get back to writing that file system that's going to fix all these horrible deficiencies in zfs. Ever heard of RMS? A file system which supports not only sequential access to files, or random access, but keyed access. (e.g. update the record whose key is 123)? A file system which allowed any program to read any file, without needing to know about its internal format? (so such an indexed file could just be read as a sequence of ordered records by applications which processed ordinary text files.) A file system which could be shared between two, or even more, running operating systems, with direct access from each system to the disks. A file system with features like access control with alarms, MAC security on a per-file basis, multiple file versions, automatic deletion of temporary files, verify-after-write. You probably wouldn't be interested; but others would. It solves a particular set of needs (primarily in the enterprise market). It did it very well. It did it some 30 years before ZFS. It's very much worthwhile listening to those who built such a system, and their experiences, if your goal is to learn about file systems. Even if they don't suffer fools gladly. If you've got a problem for which ZFS is the best solution, great. Use it. But don't think that it solves every problem, nor that it's perfect for everyone -- even you. (One particular area to think about -- how do you back up your multi-terabyte pool? And how do you restore an individual file from your backups?) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
You have me at a disadvantage here, because I'm not even a Unix (let alone Solaris and Linux) aficionado. But don't Linux snapshots in conjunction with rsync (leaving aside other possibilities that I've never heard of) provide rather similar capabilities (e.g., incremental backup or re-synching), especially when used in conjunction with scripts and cron? Which explains why you keep ranting without knowing what you're talking about. Au contraire, cookie: I present things in detail to make it possible for anyone capable of understanding the discussion to respond substantively if there's something that requires clarification or further debate. You, by contrast, babble on without saying anything substantive at all - which makes you kind of amusing, but otherwise useless. You could at least have tried to answer my question above, since you took the trouble to quote it - but of course you didn't, just babbled some more. Copy-on-write. Even a bookworm with 0 real-life-experience should be able to apply this one to a working situation. As I may well have been designing and implementing file systems since before you were born (or not: you just have a conspicuously callow air about you), my 'real-life' experience with things like COW is rather extensive. And while I don't have experience with Linux adjuncts like rsync, unlike some people I'm readily able to learn from the experience of others (who seem far more credible when describing their successful use of rsync and snapshots on Linux than anything I've seen you offer up here). There's a reason ZFS (and netapp) can take snapshots galore without destroying their filesystem performance. Indeed: it's because ZFS already sacrificed a significant portion of that performance by disregarding on-disk contiguity, so there's relatively little left to lose. By contrast, systems that respect the effects of contiguity on performance (and WAFL does to a greater degree than ZFS) reap its benefits all the time (whether snapshots exist or not) while only paying a penalty when data is changed (and they don't have to change as much data as ZFS does because they don't have to propagate changes right back to the root superblock on every update). It is possible to have nearly all of the best of both worlds, but unfortunately not with any current implementations that I know of. ZFS could at least come considerably closer, though, if it reorganized opportunistically as discussed in the database thread. (By the way, since we're talking about snapshots here rather than about clones it doesn't matter at all how many there are, so your 'snapshots galore' bluster above is just more evidence of your technical incompetence: with any reasonable implementation the only run-time overhead occurs in keeping the most recent snapshot up to date, regardless of how many older snapshots may also be present.) But let's see if you can, for once, actually step up to the plate and discuss something technically, rather than spout buzzwords that you apparently don't come even close to understanding: Are you claiming that writing snapshot before-images of modified data (as, e.g., Linux LVM snapshots do) for the relatively brief period that it takes to transfer incremental updates to another system 'destroys' performance? First of all, that's clearly dependent upon the update rate during that interval, so if it happens at a quiet time (which presumably would be arranged if its performance impact actually *was* a significant issue) your assertion is flat-out-wrong. Even if the snapshot must be processed during normal operation, maintaining it still won't be any problem if the run-time workload is read-dominated. And I suppose Sun must be lying in its documentation for fssnap (which Sun has offered since Solaris 8 with good old update-in-place UFS) where it says While the snapshot is active, users of the file system might notice a slight performance impact [as contrasted with your contention that performance is 'destroyed'] when the file system is written to, but they see no impact when the file system is read (http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV1/p185.html). You'd really better contact them right away and set them straight. Normal system cache mechanisms should typically keep about-to-be-modified data around long enough to avoid the need to read it back in from disk to create the before-image for modified data used in a snapshot, and using a log-structured approach to storing these BIs in the snapshot file or volume (though I don't know what specific approaches are used in fssnap and LVM: do you?) would be extremely efficient - resulting in minimal impact on normal system operation regardless of write activity. C'mon, cookie: surprise us for once - say something intelligent. With guidance and practice, you might even be able to make a habit of it. - bill This
Re: [zfs-discuss] Yager on ZFS
There are a category of errors that are not caused by firmware, or any type of software. The hardware just doesn't write or read the correct bit value this time around. With out a checksum there's no way for the firmware to know, and next time it very well may write or read the correct bit value from the exact same spot on the disk, so scrubbing is not going to flag this sector as 'bad'. There seems to be a lot of ignorance about how disks actually work in this thread. Here's the data path, to a first approximation. Processor = RAM = controller RAM = disk cache RAM = read/write head = media There are four buses in the above (which is a slight oversimplification): the processor/memory bus, the internal I/O bus (e.g. PCI), the external I/O bus (e.g. SATA), and the internal disk bus. (The last arrow isn't a bus, it's the magnetic field.) Errors can be introduced at any point and there are corresponding error detection and correction mechanisms at each point. Processor: Usually parity on internal registers buses, ECC on larger cache. Processor/memory bus: Usually ECC (SECDED). RAM: Usually SECDED or better for better servers, parity for cheap servers, nothing @ low-end. Internal I/O bus: Usually parity (PCI) or CRC (PCI-E). Controller RAM: Usually parity for low-end controllers, rarely ECC for high-end controllers. External I/O bus: Usually CRC. Disk cache RAM: Usually parity for low-end disks, ECC for high-end disks. Internal disk bus: Media ECC. Read/write head: N/A, doesn't hold bits. Media: Media ECC. The disk, as it's transferring data from its cache to the media, adds a very large and complex error-correction coding to the data. This protects against a huge number of errors, 20 or more bits in a single 512-byte block. This is because the media is very noisy. So there is far *better* protection than a checksum for the data once it gets to the disk, and you can't possibly (well, not within any reasonable probability) return bad data from disk. You'll get an I/O error (media error in SCSI parlance) instead. ZFS protects against an error introduced between memory and the disk. Aha!, you say, there's a lot of steps there, and we could get an error at any point! There are a lot of points there, but very few where the data isn't already protected by either CRC or parity. (Why do controllers usually use parity internally? The same reason the processor uses parity for L1; access is speed-critical, and the data is live in the cache/FIFO for such a small amount of time that the probability of a multi-bit error is negligible.) Now you may claim that this type of error happens so infrequently that it's not worth it. I do claim that the error you described -- a bit error on the disk, undetected by the disk's ECC -- is infrequent to the point of being negligible. The much more frequent case, an error which is detected but not corrected by ECC, is handled by simple mirroring. Anton This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
You have me at a disadvantage here, because I'm not even a Unix (let alone Solaris and Linux) aficionado. But don't Linux snapshots in conjunction with rsync (leaving aside other possibilities that I've never heard of) provide rather similar capabilities (e.g., incremental backup or re-synching), especially when used in conjunction with scripts and cron? Which explains why you keep ranting without knowing what you're talking about. Copy-on-write. Even a bookworm with 0 real-life-experience should be able to apply this one to a working situation. There's a reason ZFS (and netapp) can take snapshots galore without destroying their filesystem performance. Hell this one even applies *IN THEORY*, so you might not even have to *slum* with any real-world usage to grasp the concept. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Once again, profuse apologies for having taken so long (well over 24 hours by now - though I'm not sure it actually appeared in the forum until a few hours after its timestamp) to respond to this. can you guess? wrote: Primarily its checksumming features, since other open source solutions support simple disk scrubbing (which given its ability to catch most deteriorating disk sectors before they become unreadable probably has a greater effect on reliability than checksums in any environment where the hardware hasn't been slapped together so sloppily that connections are flaky). From what I've read on the subject, That premise seems bad from the tart. Then you need to read more or understand it better. I don't believe that scrubbing will catch all the types of errors that checksumming will. That's absolutely correct, but it in no way contradicts what I said (and you quoted) above. Perhaps you should read that again, more carefully: it merely states that disk scrubbing probably has a *greater* effect on reliability than checksums do, not that it completely subsumes their features. There are a category of errors that are not caused by firmware, or any type of software. The hardware just doesn't write or read the correct bit value this time around. With out a checksum there's no way for the firmware to know, and next time it very well may write or read the correct bit value from the exact same spot on the disk, so scrubbing is not going to flag this sector as 'bad'. It doesn't have to, because that's a *correctable* error that the disk's extensive correction codes (which correct *all* single-bit errors as well as most considerably longer error bursts) resolve automatically. Now you may claim that this type of error happens so infrequently No, it's actually one of the most common forms, due to the desire to pack data on the platter as tightly as possible: that's why those long correction codes were created. Rather than comment on the rest of your confused presentation about disk error rates, I'll just present a capsule review of the various kinds: 1. Correctable errors (which I just described above). If a disk notices that a sector *consistently* requires correction it may deal with it as described in the next paragraph. 2. Errors that can be corrected only with retries (i.e., the sector is not *consistently* readable even after the ECC codes have been applied, but can be successfully read after multiple attempts which can do things like fiddle slightly with the head position over the track and signal amplification to try to get a better response). A disk may try to rewrite such a sector in place to see if its readability improves as a result, and if it doesn't will then transparently revector the data to a spare sector if one exists and mark the original sector as 'bad'. Background scrubbing gives the disk an opportunity to discover such sectors *before* they become completely unreadable, thus significantly improving reliability even in non-redundant environments. 3. Uncorrectable errors (bursts too long for the ECC codes to handle even after the kinds of retries described above, but which the ECC codes can still detect): scrubbing catches these as well, and if suitable redundancy exists it can correct them by rewriting the offending sector (the disk may transparently revector it if necessary, or the LVM or file system can if the disk can't). Disk vendor specs nominally state that one such error may occur for every 10^14 bits transferred for a contemporary commodity (ATA or SATA) drive (i.e., about once in every 12.5 TB), but studies suggest that in practice they're much rarer. 4. Undetectable errors (errors which the ECC codes don't detect but which ZFS's checksums presumably would). Disk vendors no longer provide specs for this reliability metric. My recollection from a decade or more ago is that back when they used to it was three orders of magnitude lower than the uncorrectable error rate: if that still obtained it would mean about once in every 12.5 petabytes transferred, but given that the real-world incidence of uncorrectable errors is so much lower than speced and that ECC codes keep increasing in length it might be far lower than that now. ... Aside from the problems that scrubbing handles (and you need scrubbing even if you have checksums, because scrubbing is what helps you *avoid* data loss rather than just discover it after it's too late to do anything about it), and aside from problems Again I think you're wrong on the basis for your point. No: you're just confused again. The checksumming in ZFS (if I understand it correctly) isn't used for only detecting the problem. If the ZFS pool has any redundancy at all, those same checksums can be used to repair that same data, thus *avoiding* the data loss. 1. Unlike things like disk ECC codes, ZFS's checksums can't
Re: [zfs-discuss] Yager on ZFS
If you ever progress beyond counting on your fingers you might (with a lot of coaching from someone who actually cares about your intellectual development) be able to follow Anton's recent explanation of this (given that the higher-level overviews which I've provided apparently flew completely over your head). Seriously, are you 14? NOTHING anton listed takes the place of ZFS, and your pie in the sky theories do not a product make. So yet again, your long winded insult ridden response can be translated to My name is billtodd, I haven't a fucking clue, I'm wrong, so I'll defer to my usual defensive tactics of attempting to insult those who know more, and have more experience in the REAL WORLD than I. You do a GREAT job of spewing theory, you do a piss poor job of relating ANYTHING to the real world. I discussed that in detail elsewhere here yesterday (in more detail than previously in an effort to help the slower members of the class keep up). No, no you didn't. You listed of a couple of bullshit products that don't come anywhere near the features of ZFS. Let's throw out a bunch of half-completed projects that require hours of research just to setup, much less integrate, and call it done. MDADM, next up you'll tell us we really never needed to move beyond fat, because hey, that really was *good enough* too! But of course, your usual well I haven't really used the product, but I have read up on it excuse must be a get-out-of jail free card, AMIRITE?! and ease of use That actually may be a legitimate (though hardly decisive) ZFS advantage: it's too bad its developers didn't extend it farther (e.g., by eliminating the vestiges of LVM redundancy management and supporting seamless expansion to multi-node server systems). - bill Right, they definitely shouldn't have released zfs because every feature they ever plan on implementing wasn't there yet. Tell you what, why don't you try using some of these products you've read about, then you can come back and attempt to continue this discussion. I don't care what your *THEORIES* are, I care about how things work here in the real world. Better yet, you get back to writing that file system that's going to fix all these horrible deficiencies in zfs. Then you can show the world just how superior you are. *RIGHT* This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
So name these mystery alternatives that come anywhere close to the protection, If you ever progress beyond counting on your fingers you might (with a lot of coaching from someone who actually cares about your intellectual development) be able to follow Anton's recent explanation of this (given that the higher-level overviews which I've provided apparently flew completely over your head). functionality, I discussed that in detail elsewhere here yesterday (in more detail than previously in an effort to help the slower members of the class keep up). and ease of use That actually may be a legitimate (though hardly decisive) ZFS advantage: it's too bad its developers didn't extend it farther (e.g., by eliminating the vestiges of LVM redundancy management and supporting seamless expansion to multi-node server systems). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Darren, Do you happen to have any links for this? I have not seen anything about NTFS and CAS/dedupe besides some of the third party apps/services that just use NTFS as their backing store. Thanks! Wade Stuart Fallon Worldwide P: 612.758.2660 C: 612.877.0385 [EMAIL PROTECTED] wrote on 12/07/2007 12:44:31 PM: I believe the data dedup is also a feature of NTFS. -- Darren J Moffat ___ 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
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). I see you carefully snipped You would think the fact zfs was ported to freebsd so quickly would've been a good first indicator that the functionality wasn't already there. A point you appear keen to avoid discussing. Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Wed, Dec 05, 2007 at 09:45:55PM -0800, can you guess? wrote: There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be If you don't care, then go off not caring. (Can we declare this thread dead already?) Others seem to care. *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). Interoperability counts for a lot for some people. Fewer filesystems to learn about can count too. ZFS provides peace of mind that you tell us doesn't matter. And it's actively developed and you and everyone else can see that this is so, and that recent ZFS improvements and others that are in the pipe (and discussed publicly) are very good improvements, which all portends an even better future for ZFS down the line. Whatever you do not like about ZFS today may be fixed tomorrow, except for the parts about it being ZFS, opensource, Sun-developed, ..., the parts that really seem to bother you. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). Ok. So according to you, most of what ZFS does is available elsewhere, and the features it has that nothing else has are' really a value add, ar least not enough to produce a 'clear winner'. Ok, assume for a second that I believe that. can you list one other software raid/filesystem that as any feature (small or large) that ZFS lacks? Because if all else is really equal, and ZFS is the only one with any advantages then, whether those advantages are small or not (and I don't agree with how small you think they are - see my other post that you've ignored so far.) I think there is a 'clear winner' - at least at the moment - Things can change at any time. -Kyle ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Whoever coined that phrase must've been wrong, it should definitely be By billtodd you've got it. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
For the same reason he won't respond to Jone, and can't answer the original question. He's not trying to help this list out at all, or come up with any real answers. He's just here to troll. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
As I explained, there are eminently acceptable alternatives to ZFS from any objective standpoint. So name these mystery alternatives that come anywhere close to the protection, functionality, and ease of use that zfs provides. You keep talking about how they exist, yet can't seem to come up with any real names. Really, a five page dissertation isn't required. A simple numbered list will be more than acceptable. Although, I think we all know that won't happen since you haven't a list to provide. Oh and I'm sure there's something out there, I'm just not sure what DEFINITELY isn't an acceptable answer. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Dec 6, 2007 1:13 AM, Bakul Shah [EMAIL PROTECTED] wrote: Note that I don't wish to argue for/against zfs/billtodd but the comment above about no *real* opensource software alternative zfs automating checksumming and simple snapshotting caught my eye. There is an open source alternative for archiving that works quite well. venti has been available for a few years now. It runs on *BSD, linux, macOS plan9 (its native os). It uses strong crypto checksums, stored separately from the data (stored in the pointer blocks) so you get a similar guarantee against silent data corruption as ZFS. Last time I looked into Venti, it used content hashing to locate storage blocks. Which was really cool, because (as you say) it magically consolidates blocks with the same checksum together. The 45 byte score is the checksum of the top of the tree, isn't that right? Good to hear it's still alive and been revamped somewhat. ZFS snapshots and clones save a lot of space, but the 'content-hash == address' trick means you could potentially save much more. Though I'm still not sure how well it scales up - Bigger working set means you need longer (more expensive) hashes to avoid a collision, and even then its not guaranteed. When i last looked they were still using SHA-160 and I ran away screaming at that point :) Google for venti sean dorward. If interested, go to http://swtch.com/plan9port/ and pick up plan9port (a collection of programs from plan9, not just venti). See http://swtch.com/plan9port/man/man8/index.html for how to use venti. -- Rasputnik :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
[EMAIL PROTECTED] wrote on 12/06/2007 09:58:00 AM: On Dec 6, 2007 1:13 AM, Bakul Shah [EMAIL PROTECTED] wrote: Note that I don't wish to argue for/against zfs/billtodd but the comment above about no *real* opensource software alternative zfs automating checksumming and simple snapshotting caught my eye. There is an open source alternative for archiving that works quite well. venti has been available for a few years now. It runs on *BSD, linux, macOS plan9 (its native os). It uses strong crypto checksums, stored separately from the data (stored in the pointer blocks) so you get a similar guarantee against silent data corruption as ZFS. Last time I looked into Venti, it used content hashing to locate storage blocks. Which was really cool, because (as you say) it magically consolidates blocks with the same checksum together. The 45 byte score is the checksum of the top of the tree, isn't that right? Good to hear it's still alive and been revamped somewhat. ZFS snapshots and clones save a lot of space, but the 'content-hash == address' trick means you could potentially save much more. Though I'm still not sure how well it scales up - Bigger working set means you need longer (more expensive) hashes to avoid a collision, and even then its not guaranteed. When i last looked they were still using SHA-160 and I ran away screaming at that point :) The hash chosen is close to inconsequential as long as you perform collision checks and the collision rate is low. Hash key collision branching is pretty easy and has been used for decades (see perl's collision forking for hash var key collisions for an example). The process is lookup a key, verify data matches, if it does inc the ref count store and go, if no match split out a sub key, store and go. There are cost curves for both the hashing, and data matching portions. As the number of hash matches goes up so does the cost for data verifying -- but no matter what hash you use (assuming at least one bit less information then the original data) there _will_ be collisions possible so the verify must exist. -Wade ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
apologies in advance for prolonging this thread ..
Why do you feel any need to? If you were contributing posts as completely
devoid of technical content as some of the morons here have recently been
submitting I could understand it, but my impression is that the purpose of this
forum is to explore the kind of questions that you're interested in discussing.
i
had considered
taking this completely offline, but thought of a few
people at least
who might find this discussion somewhat interesting
And any who don't are free to ignore it, so no harm done there either.
.. at the least i
haven't seen any mention of Merkle trees yet as the
nerd in me yearns
for
I'd never heard of them myself until recently, despite having come up with the
idea independently to use a checksumming mechanism very similar to ZFS's.
Merkle seems to be an interesting guy - his home page is worth a visit.
On Dec 5, 2007, at 19:42, bill todd - aka can you
guess? wrote:
what are you terming as ZFS' incremental risk
reduction? ..
(seems like a leading statement toward a
particular assumption)
Primarily its checksumming features, since other
open source
solutions support simple disk scrubbing (which
given its ability to
catch most deteriorating disk sectors before they
become unreadable
probably has a greater effect on reliability than
checksums in any
environment where the hardware hasn't been slapped
together so
sloppily that connections are flaky).
ah .. okay - at first reading incremental risk
reduction seems to
imply an incomplete approach to risk
The intent was to suggest a step-wise approach to risk, where some steps are
far more significant than others (though of course some degree of overlap
between steps is also possible).
*All* approaches to risk are incomplete.
...
i do
believe that an interesting use of the merkle tree
with a sha256 hash
is somewhat of an improvement over conventional
volume based data
scrubbing techniques
Of course it is: that's why I described it as 'incremental' rather than as
'redundant'. The question is just how *significant* an improvement it offers.
since there can be a unique
integration between
the hash tree for the filesystem block layout and a
hierarchical data
validation method. In addition to the finding
unknown areas with the
scrub, you're also doing relatively inexpensive data
validation
checks on every read.
Yup.
...
sure - we've seen many transport errors,
I'm curious what you mean by that, since CRCs on the transports usually
virtually eliminate them as problems. Unless you mean that you've seen many
*corrected* transport errors (indicating that the CRC and retry mechanisms are
doing their job and that additional ZFS protection in this area is probably
redundant).
as well as
firmware
implementation errors
Quantitative and specific examples are always good for this kind of thing; the
specific hardware involved is especially significant to discussions of the sort
that we're having (given ZFS's emphasis on eliminating the need for much
special-purpose hardware).
.. in fact with many arrays
we've seen data
corruption issues with the scrub
I'm not sure exactly what you're saying here: is it that the scrub has
*uncovered* many apparent instances of data corruption (as distinct from, e.g.,
merely unreadable disk sectors)?
(particularly if the
checksum is
singly stored along with the data block)
Since (with the possible exception of the superblock) ZFS never stores a
checksum 'along with the data block', I'm not sure what you're saying there
either.
- just like
spam you really
want to eliminate false positives that could indicate
corruption
where there isn't any.
The only risk that ZFS's checksums run is the infinitesimal possibility that
corruption won't be detected, not that they'll return a false positive.
if you take some time to read
the on disk
format for ZFS you'll see that there's a tradeoff
that's done in
favor of storing more checksums in many different
areas instead of
making more room for direct block pointers.
While I haven't read that yet, I'm familiar with the trade-off between using
extremely wide checksums (as ZFS does - I'm not really sure why, since
cryptographic-level security doesn't seem necessary in this application) and
limiting the depth of the indirect block tree. But (yet again) I'm not sure
what you're trying to get at here.
...
on this list we've seen a number of consumer
level products
including sata controllers, and raid cards (which are
also becoming
more commonplace in the consumer realm) that can be
confirmed to
throw data errors.
Your phrasing here is a bit unusual ('throwing errors' - or exceptions - is not
commonly related to corrupting data). If you're referring to some kind of
silent data corruption, once again specifics are important: to put it
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). I see you carefully snipped You would think the fact zfs was ported to freebsd so quickly would've been a good first indicator that the functionality wasn't already there. A point you appear keen to avoid discussing. Hmmm - do I detect yet another psychic-in-training here? Simply ignoring something that one considers irrelevant does not necessarily imply any active desire to *avoid* discussing it. I suspect that whoever ported ZFS to FreeBSD was a fairly uncritical enthusiast just as so many here appear to be (and I'll observe once again that it's very easy to be one, because ZFS does sound impressive until you really begin looking at it closely). Not to mention the fact that open-source operating systems often gather optional features more just because they can than because they necessarily offer significant value: all it takes is one individual who (for whatever reason) feels like doing the work. Linux, for example, is up to its ears in file systems, all of which someone presumably felt it worthwhile to introduce there. Perhaps FreeBSD proponents saw an opportunity to narrow the gap in this area (especially since incorporating ZFS into Linux appears to have licensing obstacles). In any event, the subject under discussion here is not popularity but utility - *quantifiable* utility - and hence the porting of ZFS to FreeBSD is not directly relevant. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
(Can we declare this thread dead already?) Many have already tried, but it seems to have a great deal of staying power. You, for example, have just contributed to its continued vitality. Others seem to care. *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). Interoperability counts for a lot for some people. Then you'd better work harder on resolving the licensing issues with Linux. Fewer filesystems to earn about can count too. And since ZFS differs significantly from its more conventional competitors, that's something of an impediment to acceptance. ZFS provides peace of mind that you tell us doesn't matter. Sure it matters, if it gives that to you: just don't pretend that it's of any *objective* significance, because *that* requires actual quantification. And it's actively developed and you and everyone else can see that this is so, Sort of like ext2/3/4, and XFS/JFS (though the latter have the advantage of already being very mature, hence need somewhat less 'active' development). and that recent ZFS improvements and others that are in the pipe (and discussed publicly) are very good improvements, which all portends an even better future for ZFS down the line. Hey, it could even become a leadership product someday. Or not - time will tell. Whatever you do not like about ZFS today may be fixed tomorrow, There'd be more hope for that if its developers and users seemed less obtuse. except for the parts about it being ZFS, opensource, Sun-developed, ..., the parts that really seem to bother you. Specific citations of material that I've posted that gave you that impression would be useful: otherwise, you just look like another self-professed psychic (is this a general characteristic of Sun worshipers, or just of ZFS fanboys?). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
The 45 byte score is the checksum of the top of the tree, isn't that right? Yes. Plus an optional label. ZFS snapshots and clones save a lot of space, but the 'content-hash == address' trick means you could potentially save much more. Especially if you carry around large files (disk images, databases) that change. Though I'm still not sure how well it scales up - Bigger working set means you need longer (more expensive) hashes to avoid a collision, and even then its not guaranteed. When i last looked they were still using SHA-160 and I ran away screaming at that point :) You need 2^80 blocks for a 50%+ probability that a pair will have the same SHA-160 hash (by the birthday paradox). Crypto attacks are not relevant. For my personal use I am willing to live with these odds until my backups cross 2^40 distinct blocks (greater than 8 Petabytes)! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
STILL haven't given us a list of these filesystems you say match what zfs does. STILL coming back with long winded responses with no content whatsoever to try to divert the topic at hand. And STILL making incorrect assumptions. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). Ok. So according to you, most of what ZFS does is available elsewhere, and the features it has that nothing else has are' really a value add, ar least not enough to produce a 'clear winner'. Ok, assume for a second that I believe that. Unlike so many here I don't assume things lightly - and this one seems particularly shaky. can you list one other software raid/filesystem that as any feature (small or large) that ZFS lacks? Well, duh. Because if all else is really equal, and ZFS is the only one with any advantages then, whether those advantages are small or not (and I don't agree with how small you think they are - see my other post that you've ignored so far.) Sorry - I do need to sleep sometimes. But I'll get right to it, I assure you (or at worst soon: time has gotten away from me again and I've got an appointment to keep this afternoon). I think there is a 'clear winner' - at least at the moment - Things can change at any time. You don't get out much, do you? How does ZFS fall short of other open-source competitors (I'll limit myself to them, because once you get into proprietary systems - and away from the quaint limitations of Unix file systems - the list becomes utterly unmanageable)? Let us count the ways (well, at least the ones that someone as uninformed as I am about open-source features can come up with off the top of his head), starting in the volume-management arena: 1. RAID-Z, as I've explained elsewhere, is brain-damaged when it comes to effective disk utilization for small accesses (especially reads): RAID-5 offers the same space efficiency with N times the throughput for such workloads (used to be provided by mdadm on Linux unless the Linux LVM now supports it too). 2. DRDB on Linux supports remote replication (IIRC there was an earlier, simpler mechanism that also did). 3. Can you yet shuffle data off a disk such that it can be removed from a zpool? LVM on Linux supports this. 4. Last I knew, you couldn't change the number of disks in a RAID-Z stripe at all, let alone reorganize existing stripe layout on the fly. Typical hardware RAIDs can do this and I thought that Linux RAID support could as well, but can't find verification now - so I may have been remembering a proposed enhancement. And in the file system arena: 5. No user/group quotas? What *were* they thinking? The discussions about quotas here make it clear that per-filesystem quotas are not an adequate alternative: leaving aside the difficulty of simulating both user *and* group quotas using that mechanism, using it raises mount problems when very large numbers of users are involved, plus hard-link and NFS issues crossing mount points. 6. ZFS's total disregard of on-disk file contiguity can torpedo sequential-access performance by well over a decimal order of magnitude in situations where files either start out severely fragmented (due to heavily parallel write activity during their population) or become so due to fine-grained random updates. 7. ZFS's full-path COW approach increases the space overhead of snapshots compared with conventional file systems. 8. Not available on Linux. Damn - I've got to run. Perhaps others more familiar with open-source alternatives will add to this list while I'm out. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
I suspect ZFS will change that game in the future. In particular for someone doing lots of editing, snapshots can help recover from user error. Ah - so now the rationalization has changed to snapshot support. Unfortunately for ZFS, snapshot support is pretty commonly available We can cherry pick features all day. People choose ZFS for the combination (as well as its unique features). Actually, based on the self-selected and decidedly unscientific sample of ZFS proponents that I've encountered around the Web lately, it appears that people choose ZFS in large part because a) they've swallowed the Last Word In File Systems viral marketing mantra hook, line, and sinker (that's in itself not all that surprising, because the really nitty-gritty details of file system implementation aren't exactly prime topics of household conversation - even among the technically inclined), b) they've incorporated this mantra into their own self-image (the 'fanboy' phenomenon - but at least in the case of existing Sun customers this is also not very surprising, because dependency on a vendor always tends to engender loyalty - especially if that vendor is not doing all that well and its remaining customers have become increasingly desperate for good news that will reassure them). and/or c) they're open-source zealots who've been sucked in by Jonathan's recent attempt to turn t he patent dispute with NetApp into something more profound than the mundane inter-corporation spat which it so clearly is. All of which certainly helps explain why so many of those proponents are so resistant to rational argument: their zeal is not technically based, just technically rationalized (as I was pointing out in the post to which you responded) - much more like the approach of a (volunteer) marketeer with an agenda than like that of an objective analyst (not to suggest that *no one* uses ZFS based on an objective appreciation of the trade-offs involved in doing so, of course - just that a lot of its more vociferous supporters apparently don't). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: As I said in the post to which you responded, I consider ZFS's ease of management to be more important (given that even in high-end installations storage management costs dwarf storage equipment costs) than its real but relatively marginal reliability edge, and that's the context in which I made my comment about alternatives (though even there if ZFS continues to require definition of mirror pairs and parity groups for redundancy that reduces its ease-of-management edge, as does its limitation to a single host system in terms of ease-of-scaling). Specifically, features like snapshots, disk scrubbing (to improve reliability by dramatically reducing the likelihood of encountering an unreadable sector during a RAID rebuild), and software RAID (to reduce hardware costs) have been available for some time in Linux and FreeBSD, and canned management aids would not be difficult to develop if they don't exist already. The dreaded 'write hole' in software RAID is a relatively minor exposure (since it only compromises data if a system crash or UPS failure - both rare events in an enterprise setting - sneaks in between a data write and the corresponding parity update and then, before the array has restored parity consistency in the background, a disk dies) - and that exposure can be reduced to seconds by a minuscule amount of NVRAM that remembers which writes were active (or to zero with somewhat more NVRAM to remember the updates themselves in an inexpensive hardware solution). The real question is usually what level of risk an enterprise storage user is willing to tolerate. At the paranoid end of the scale reside the users who will accept nothing less than z-series or Tandem-/Stratus-style end-to-end hardware checking from the processor traces on out - which rules out most environments that ZFS runs in (unless Sun's N-series telco products might fill the bill: I'm not very familiar with them). And once you get down into users of commodity processors, the risk level of using stable and robust file systems that lack ZFS's additional integrity checks is comparable to the risk inherent in the rest of the system (at least if the systems are carefully constructed, which should be a given in an enterprise setting) - so other open-source solutions are definitely in play there. All things being equal, of course users would opt for even marginally higher reliability - but all things are never equal. If using ZFS would require changing platforms or changing code, that's almost certainly a show-stopper for enterprise users. If using ZFS would compromise performance or require changes in management practices (e.g., to accommodate file-system-level quotas), those are at least significant impediments. In other words, ZFS has its pluses and minuses just as other open-source file systems do, and they *all* have the potential to start edging out expensive proprietary solutions in *some* applications (and in fact have already started to do so). When we move from 'current' to 'potential' alternatives, the scope for competition widens. Because it's certainly possible to create a file system that has all of ZFS's added reliability but runs faster, scales better, incorporates additional useful features, and is easier to manage. That discussion is the one that would take a lot of time to delve into adequately (and might be considered off topic for this forum - which is why I've tried to concentrate here on improvements that ZFS could actually incorporate without turning it upside down). - bill my personal-professional data are important (this is my valuation, and it's an assumption you can't dispute). my data are only digital and rapidly changing, and than I cannot print them. I have budget constraints then I can use only user-level storage. until I discovered zfs I used subversion and git, but none of them is designed to manage gigabytes of data, some to be versioned, some to be unversioned. I can't afford silent data corruption and, if the final response is *now* there is no *real* opensource software alternative to zfs automatic checksumming and simple snapshotting I'll be an happy solaris user (for data storage), an happy linux user (for everyday work), and an unhappy offline windows user (for some video-related activity I can't do with linux). PS I think for every fully digital people own data are vital, and almost everyone would reply NONE at your question what level of risk user is willing to tolerate. bye --- Stefano Spinucci This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Why are we still feeding this troll? Paid trolls deserve no response and there is no value in continuing this thread. (And no guys, he isn't being paid by NetApp.. think bigger) The troll will continue to try to downplay features of zfs and the community will counter...and on and on. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
my personal-professional data are important (this is my valuation, and it's an assumption you can't dispute). Nor was I attempting to: I was trying to get you to evaluate ZFS's incremental risk reduction *quantitatively* (and if you actually did so you'd likely be surprised at how little difference it makes - at least if you're at all rational about assessing it). ... I think for every fully digital people own data are vital, and almost everyone would reply NONE at your question what level of risk user is willing to tolerate. The fact that appears to escape people like you it that there is *always* some risk, and you *have* to tolerate it (or not save anything at all). Therefore the issue changes to just how *much* risk you're willing to tolerate for a given amount of effort. (There's also always the possibility of silent data corruption, even if you use ZFS - because it only eliminates *some* of the causes of such corruption. If your data is corrupted in RAM during the period when ZFS is not watching over it, for example, you're SOL.) How to *really* protect valuable data has already been thoroughly discussed in this thread, though you don't appear to have understood it. It takes multiple copies (most of them off-line), in multiple locations, with verification of every copy operation and occasional re-verification of the stored content - and ZFS helps with only part of one of these strategies (reverifying the integrity of your on-line copy). If you don't take the rest of the steps, ZFS's incremental protection is virtually useless, because the risk of data loss from causes that ZFS doesn't protect against is so much higher than the incremental protection that it provides (i.e., you may *feel* noticeably better protected but you're just kidding yourself). If you *do* take the rest of the steps, then it takes little additional effort to revalidate your on-line content as well as the off-line copies, so all ZFS provides is a small reduction in effort to achieve the same (very respectable) level of protecti on that other solutions can achieve when manual steps are taken to reverify the on-line copy as well as the off-line copies. Try to step out of your my data is valuable rut and wrap your mind around the fact that ZFS's marginal contribution to its protection, real though it may be, just isn't very significant in most environments compared to the rest of the protection solution that it *doesn't* help with. That's why I encouraged you to *quantify* the effect that ZFS's protection features have in *your* environment (along with its other risks that ZFS can't ameliorate): until you do that, you're just another fanboy (not that there's anything wrong with that, as long as you don't try to present your personal beliefs as something of more objective validity). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
trolling can you guess? wrote: he isn't being paid by NetApp.. think bigger O frabjous day! Yet *another* self-professed psychic, but one whose internal voices offer different counsel. While I don't have to be psychic myself to know that they're *all* wrong (that's an advantage of fact-based rather than faith-based opinions), a battle-of-the-incompetents would be amusing to watch (unless it took place in a realm which no mere mortals could visit). - bill /trolling ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 5-Dec-07, at 4:19 AM, can you guess? wrote: On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; So the question is: do you really need that feature (please quantify that need if you think you do), or do you just like it because it makes you feel all warm and safe? Warm and safe is definitely a nice feeling, of course, but out in the real world of corporate purchasing it's just one feature out of many 'nice to haves' - and not necessarily the most important. In particular, if the *actual* risk reduction turns out to be relatively minor, that nice 'feeling' doesn't carry all that much weight. On the other hand, it's hard to argue for risk *increase* (using something else)... --Toby you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? As I said in the post to which you responded, I consider ZFS's ease of management to be more important (given that even in high-end installations storage management costs dwarf storage equipment costs) than its real but relatively marginal reliability edge, and that's the context in which I made my comment about alternatives (though even there if ZFS continues to require definition of mirror pairs and parity groups for redundancy that reduces its ease-of- management edge, as does its limitation to a single host system in terms of ease-of-scaling). Specifically, features like snapshots, disk scrubbing (to improve reliability by dramatically reducing the likelihood of encountering an unreadable sector during a RAID rebuild), and software RAID (to reduce hardware costs) have been available for some time in Linux and FreeBSD, and canned management aids would not be difficult to develop if they don't exist already. The dreaded 'write hole' in software RAID is a relatively minor exposure (since it only compromises data if a system crash or UPS failure - both rare events in an enterprise setting - sneaks in between a data write and the corresponding parity update and then, before the array has restored parity consistency in the background, a disk dies) - and that exposure can be reduced to seconds by a minuscule amount of NVRAM that remembers which writes were active (or to zero with somewhat more NVRAM to remember the updates themselves in an inexpensive hardware solution). The real question is usually what level of risk an enterprise storage user is willing to tolerate. At the paranoid end of the scale reside the users who will accept nothing less than z-series or Tandem-/Stratus-style end-to-end hardware checking from the processor traces on out - which rules out most environments that ZFS runs in (unless Sun's N-series telco products might fill the bill: I'm not very familiar with them). And once you get down into users of commodity processors, the risk level of using stable and robust file systems that lack ZFS's additional integrity checks is comparable to the risk inherent in the rest of the system (at least if the systems are carefully constructed, which should be a given in an enterprise setting) - so other open-source solutions are definitely in play there. All things being equal, of course users would opt for even marginally higher reliability - but all things are never equal. If using ZFS would require changing platforms or changing code, that's almost certainly a show-stopper for enterprise users. If using ZFS would compromise performance or require changes in management practices (e.g., to accommodate file-system-level quotas), those are at least significant impediments. In other words, ZFS has its pluses and minuses just as other open-source file systems do, and they *all* have the potential to start edging out expensive proprietary solutions in *some* applications (and in fact have already started to do so). When we move from 'current' to 'potential' alternatives, the scope for competition widens. Because it's certainly possible to create a file system that has all of ZFS's added reliability but runs faster, scales better, incorporates additional useful features, and is easier to manage. That discussion is the one that would take a lot of time to delve into adequately (and might be considered off topic for this forum - which is why I've
Re: [zfs-discuss] Yager on ZFS
On 4-Dec-07, at 9:35 AM, can you guess? wrote: Your response here appears to refer to a different post in this thread. I never said I was a typical consumer. Then it's unclear how your comment related to the material which you quoted (and hence to which it was apparently responding). If you look around photo forums, you'll see an interest the digital workflow which includes long term storage and archiving. A chunk of these users will opt for an external RAID box (10%? 20%?). I suspect ZFS will change that game in the future. In particular for someone doing lots of editing, snapshots can help recover from user error. Ah - so now the rationalization has changed to snapshot support. Unfortunately for ZFS, snapshot support is pretty commonly available We can cherry pick features all day. People choose ZFS for the combination (as well as its unique features). --Toby (e.g., in Linux's LVM - and IIRC BSD's as well - if you're looking at open-source solutions) so anyone who actually found this feature important has had access to it for quite a while already. And my original comment which you quoted still obtains as far as typical consumers are concerned. - 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
Re: [zfs-discuss] Yager on ZFS
I have budget constraints then I can use only user-level storage. until I discovered zfs I used subversion and git, but none of them is designe d to manage gigabytes of data, some to be versioned, some to be unversioned. I can't afford silent data corruption and, if the final response is *now* th ere is no *real* opensource software alternative to zfs automatic checksummin g and simple snapshotting I'll be an happy solaris user (for data storage), an happy linux user (for everyday work), and an unhappy offline windows user (for some video-related activity I can't do with linux). Note that I don't wish to argue for/against zfs/billtodd but the comment above about no *real* opensource software alternative zfs automating checksumming and simple snapshotting caught my eye. There is an open source alternative for archiving that works quite well. venti has been available for a few years now. It runs on *BSD, linux, macOS plan9 (its native os). It uses strong crypto checksums, stored separately from the data (stored in the pointer blocks) so you get a similar guarantee against silent data corruption as ZFS. You can back up a variety of filesystems (ufs, hfs, ext2fs, fat) or use it to to backup a file tree. Each backup results in a single 45 byte score containing the checksum of root pointer block. Using this score you can retrieve the entire backup. Further, it stores only one copy of a data block regardless of what files or which backup it may belong to. In effect every full backup is an incremental backup (only changed data blocks and changed or new ptr blocks are stored). So it is really an archival server. You don't take snapshots but you do a backup. However you can nfs mount a venti and all your backups will show up under directories like machine//mmdd/filesystem. Ideally you'd store a venti on RAID storage. You can even copy a bunch of venti to another one, you can store its arenas on CDs or DVD and so on. It is not as fast as ZFS nor anywhere near as easy to use and its intended use is not the same as ZFS (not a primary filesystem). But for what it does, it is not bad at all! Unlike ZFS, it fits best where you have a fast filesystem for speed critical use, venti for backups and RAID for redundancy. Google for venti sean dorward. If interested, go to http://swtch.com/plan9port/ and pick up plan9port (a collection of programs from plan9, not just venti). See http://swtch.com/plan9port/man/man8/index.html for how to use venti. I think for every fully digital people own data are vital, and almost everyon e would reply NONE at your question what level of risk user is willing to tolerate. NONE is not possible. It is a question of how much risk you are willing to tolerate for what cost. Thankfully, these days you have a variety of choices and much much lower cost for a given degree of risk compared to just a few years ago! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Tue, 4 Dec 2007, Stefano Spinucci wrote: On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? if I missed something tell me, and I'll happily stay with linux with my data checksummed and snapshotted. bye --- Stefano Spinucci Hi Stefano, Did you get a *real* answer to your question? Do you think that this (quoted) message is a *real* answer? can you guess? --- Message-ID: [EMAIL PROTECTED] Date: Tue, 04 Dec 2007 22:19:54 PST From: can you guess? [EMAIL PROTECTED] To: zfs-discuss@opensolaris.org In-Reply-To: [EMAIL PROTECTED] Subject: Re: [zfs-discuss] Yager on ZFS List-Id: zfs-discuss.opensolaris.org On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; So the question is: do you really need that feature (please quantify that need if you think you do), or do you just like it because it makes you feel all warm and safe? Warm and safe is definitely a nice feeling, of course, but out in the real world of corporate purchasing it's just one feature out of many 'nice to haves' - and not necessarily the most important. In particular, if the *actual* risk reduction turns out to be relatively minor, that nice 'feeling' doesn't carry all that much weight. you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? As I said in the post to which you responded, I consider ZFS's ease of management to be more important (given that even in high-end installations storage management costs dwarf storage equipment costs) than its real but relatively marginal reliability edge, and that's the context in which I made my comment about alternatives (though even there if ZFS continues to require definition of mirror pairs and parity groups for redundancy that reduces its ease-of-management edge, as does its limitation to a single host system in terms of ease-of-scaling). Specifically, features like snapshots, disk scrubbing (to improve reliability by dramatically reducing the likelihood of encountering an unreadable sector during a RAID rebuild), and software RAID (to reduce hardware costs) have been available for some time in Linux and FreeBSD, and canned management aids would not be difficult to develop if they don't exist already. The dreaded 'write hole' in software RAID is a relatively minor exposure (since it only compromises data if a system crash or UPS failure - both rare events in an enterprise setting - sneaks in between a data write and the corresponding parity update and then, before the array has restored parity consistency in the background, a disk dies) - and that exposure can be reduced to seconds by a minuscule amount of NVRAM that remembers which writes were active (or to zero with somewhat more NVRAM to remember the updates themselves in an inexpensive hardware solution). The real question is usually what level of risk an enterprise storage user is willing to tolerate. At the paranoid end of the scale reside the users who will accept nothing less than z-series or Tandem-/Stratus-style end-to-end hardware checking from the processor traces on out - which rules out most environments that ZFS runs in (unless Sun's N-series telco products might fill the bill: I'm not very familiar with them). And once you get down into users of commodity processors, the risk level of using stable and robust file systems that lack ZFS's additional integrity checks is comparable to the risk inherent in the rest of the system (at least if the systems are carefully constructed, which should be a given in an enterprise setting) - so other open-source solutions are definitely in play there. All things being equal, of course users would opt
Re: [zfs-discuss] Yager on ZFS
I was trying to get you to evaluate ZFS's incremental risk reduction *quantitatively* (and if you actually did so you'd likely be surprised at how little difference it makes - at least if you're at all rational about assessing it). ok .. i'll bite since there's no ignore feature on the list yet: what are you terming as ZFS' incremental risk reduction? .. (seems like a leading statement toward a particular assumption) Primarily its checksumming features, since other open source solutions support simple disk scrubbing (which given its ability to catch most deteriorating disk sectors before they become unreadable probably has a greater effect on reliability than checksums in any environment where the hardware hasn't been slapped together so sloppily that connections are flaky). Aside from the problems that scrubbing handles (and you need scrubbing even if you have checksums, because scrubbing is what helps you *avoid* data loss rather than just discover it after it's too late to do anything about it), and aside from problems deriving from sloppy assembly (which tend to become obvious fairly quickly, though it's certainly possible for some to be more subtle), checksums primarily catch things like bugs in storage firmware and otherwise undetected disk read errors (which occur orders of magnitude less frequently than uncorrectable read errors). Robert Milkowski cited some sobering evidence that mid-range arrays may have non-negligible firmware problems that ZFS could often catch, but a) those are hardly 'consumer' products (to address that sub-thread, which I think is what applies in Stefano's case) and b) ZFS's claimed attraction for higher-end (corporate) use is its ability to *eliminate* the need for such products (hence its ability to catch their bugs would not apply - though I can understand why people who needed to use them anyway might like to have ZFS's integrity checks along for the ride, especially when using less-than-fully-mature firmware). And otherwise undetected disk errors occur with negligible frequency compared with software errors that can silently trash your data in ZFS cache or in application buffers (especially in PC environments: enterprise software at least tends to be more stable and more carefully controlled - not to mention their typical use of ECC RAM). So depending upon ZFS's checksums to protect your data in most PC environments is sort of like leaving on a vacation and locking and bolting the back door of your house while leaving the front door wide open: yes, a burglar is less likely to enter by the back door, but thinking that the extra bolt there made you much safer is likely foolish. .. are you just trying to say that without multiple copies of data in multiple physical locations you're not really accomplishing a more complete risk reduction What I'm saying is that if you *really* care about your data, then you need to be willing to make the effort to lock and bolt the front door as well as the back door and install an alarm system: if you do that, *then* ZFS's additional protection mechanisms may start to become significant (because you're eliminated the higher-probability risks and ZFS's extra protection then actually reduces the *remaining* risk by a significant percentage). Conversely, if you don't care enough about your data to take those extra steps, then adding ZFS's incremental protection won't reduce your net risk by a significant percentage (because the other risks that still remain are so much larger). Was my point really that unclear before? It seems as if this must be at least the third or fourth time that I've explained it. yes i have read this thread, as well as many of your other posts around usenet and such .. in general i find your tone to be somewhat demeaning (slightly rude too - but - eh, who's counting? i'm none to judge) As I've said multiple times before, I respond to people in the manner they seem to deserve. This thread has gone on long enough that there's little excuse for continued obtuseness at this point, but I still attempt to be pleasant as long as I'm not responding to something verging on being hostile. - now, you do know that we are currently in an era of collaboration instead of deconstruction right? Can't tell it from the political climate, and corporations seem to be following that lead (I guess they've finally stopped just gazing in slack-jawed disbelief at what this administration is getting away with and decided to cash in on the opportunity themselves). Or were you referring to something else? .. so i'd love to see the improvements on the many shortcomings you're pointing to and passionate about written up, proposed, and freely implemented :) Then ask the ZFS developers to get on the stick: fixing the fragmentation problem discussed elsewhere should be easy, and RAID-Z is at least amenable to a
Re: [zfs-discuss] Yager on ZFS
That would require coming up with something solid. Much like his generalization that there's already snapshotting and checksumming that exists for linux. yet when he was called out, he responded with a 20 page rant because there doesn't exist such a solution. It's far easier to condescend when called out on your BS than to actually answer the question. If there were such a solution available, it would've been a one line response. IE: sure, xfs has checksumming and snapshotting today in linux!!111 But alas, nothing does exist, which is exactly why there's so much interest in zfs. but most consumers won't need what it provides is a cop-out, as he knows. Just like *most consumers* don't need more than 128kbit/sec of bandwidth, and *most consumers* didn't need bigger than a 10MB hard drive. It turns out people tend to use the technology AFTER it's developed. OF COURSE the need is a niche right now, just like every other technology before it. It HAS to be by the very nature that people can't use what they don't have. 10 years ago I couldn't download an entire CD without waiting a couple days, and shockingly enough, there was no *consumer need* to do so. Go figure, 10 years later, the bandwidth is there, and there's a million other technologies built up around it. But I digress, he's already assured us all he loves ZFS and isn't just trolling these forums. Clearly that statement trumps any and all actions that proceeded it. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Dec 5, 2007, at 17:50, can you guess? wrote: my personal-professional data are important (this is my valuation, and it's an assumption you can't dispute). Nor was I attempting to: I was trying to get you to evaluate ZFS's incremental risk reduction *quantitatively* (and if you actually did so you'd likely be surprised at how little difference it makes - at least if you're at all rational about assessing it). ok .. i'll bite since there's no ignore feature on the list yet: what are you terming as ZFS' incremental risk reduction? .. (seems like a leading statement toward a particular assumption) .. are you just trying to say that without multiple copies of data in multiple physical locations you're not really accomplishing a more complete risk reduction yes i have read this thread, as well as many of your other posts around usenet and such .. in general i find your tone to be somewhat demeaning (slightly rude too - but - eh, who's counting? i'm none to judge) - now, you do know that we are currently in an era of collaboration instead of deconstruction right? .. so i'd love to see the improvements on the many shortcomings you're pointing to and passionate about written up, proposed, and freely implemented :) --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
he isn't being paid by NetApp.. think bigger O frabjous day! Yet *another* self-professed psychic, but one whose internal voices offer different counsel. While I don't have to be psychic myself to know that they're *all* wrong (that's an advantage of fact-based rather than faith-based opinions), a battle-of-the-incompetents would be amusing to watch (unless it took place in a realm which no mere mortals could visit). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Wed, 5 Dec 2007, Eric Haycraft wrote: [... reformatted ] Why are we still feeding this troll? Paid trolls deserve no response and there is no value in continuing this thread. (And no guys, he isn't being paid by NetApp.. think bigger) The troll will continue to try to downplay features of zfs and the community will counter...and on and on. +1 - a troll Ques: does it matter why he's a troll? I don't think so but my best guess is that Bill is out of work, and, due to the financial hardship, has had to cut his alzheimer's medication dosage in half. I could be wrong, with my guess, but as long as I keep seeing this can you guess? question, I feel compelled to answer it. :) Please feel free to offer your best can you guess? answer! 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
Re: [zfs-discuss] Yager on ZFS
... Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; So the question is: do you really need that feature (please quantify that need if you think you do), or do you just like it because it makes you feel all warm and safe? Warm and safe is definitely a nice feeling, of course, but out in the real world of corporate purchasing it's just one feature out of many 'nice to haves' - and not necessarily the most important. In particular, if the *actual* risk reduction turns out to be relatively minor, that nice 'feeling' doesn't carry all that much weight. On the other hand, it's hard to argue for risk *increase* (using something else)... And no one that I'm aware of was doing anything like that: what part of the All things being equal paragraph (I've left it in below in case you missed it the first time around) did you find difficult to understand? - bill ... All things being equal, of course users would opt for even marginally higher reliability - but all things are never equal. If using ZFS would require changing platforms or changing code, that's almost certainly a show-stopper for enterprise users. If using ZFS would compromise performance or require changes in management practices (e.g., to accommodate file-system-level quotas), those are at least significant impediments. In other words, ZFS has its pluses and minuses just as other open-source file systems do, and they *all* have the potential to start edging out expensive proprietary solutions in *some* applications (and in fact have already started to do so). This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: Primarily its checksumming features, since other open source solutions support simple disk scrubbing (which given its ability to catch most deteriorating disk sectors before they become unreadable probably has a greater effect on reliability than checksums in any environment where the hardware hasn't been slapped together so sloppily that connections are flaky). From what I've read on the subject, That premise seems bad from the start. I don't believe that scrubbing will catch all the types of errors that checksumming will. There are a category of errors that are not caused by firmware, or any type of software. The hardware just doesn't write or read the correct bit value this time around. With out a checksum there's no way for the firmware to know, and next time it very well may write or read the correct bit value from the exact same spot on the disk, so scrubbing is not going to flag this sector as 'bad'. Now you may claim that this type of error happens so infrequently that it's not worth it. You may think so since the number of bits you need to read or write to experience this is huge. However, hard disk sizes are still increasing exponentially, and the data we users are storing on them is too. I don't believe that the distinctive makers are making corresponding improvements in the bit error rates. Therefore while it may not be a huge benefit today, it's good we have it today, because it's value will increase as time goes on, drive sizes and data sizes increase. Aside from the problems that scrubbing handles (and you need scrubbing even if you have checksums, because scrubbing is what helps you *avoid* data loss rather than just discover it after it's too late to do anything about it), and aside from problems Again I think you're wrong on the basis for your point. The checksumming in ZFS (if I understand it correctly) isn't used for only detecting the problem. If the ZFS pool has any redundancy at all, those same checksums can be used to repair that same data, thus *avoiding* the data loss. I agree that scrubbing is still a good idea. but as discussed above it won't catch (and avoid) all the types of errors that checksumming can catch *and repair*. deriving from sloppy assembly (which tend to become obvious fairly quickly, though it's certainly possible for some to be more subtle), checksums primarily catch things like bugs in storage firmware and otherwise undetected disk read errors (which occur orders of magnitude less frequently than uncorrectable read errors). Sloppy assembly isn't the only place these errors can occur. it can occur between the head and the platter, even with the best drive and controller firmware. Robert Milkowski cited some sobering evidence that mid-range arrays may have non-negligible firmware problems that ZFS could often catch, but a) those are hardly 'consumer' products (to address that sub-thread, which I think is what applies in Stefano's case) and b) ZFS's claimed attraction for higher-end (corporate) use is its ability to *eliminate* the need for such products (hence its ability to catch their bugs would not apply - though I can understand why people who needed to use them anyway might like to have ZFS's integrity checks along for the ride, especially when using less-than-fully-mature firmware). Every drive has firmware too. If it can be used to detect and repair array firmware problems, then it can be used by consumers to detect and repair drive firmware problems too. And otherwise undetected disk errors occur with negligible frequency compared with software errors that can silently trash your data in ZFS cache or in application buffers (especially in PC environments: enterprise software at least tends to be more stable and more carefully controlled - not to mention their typical use of ECC RAM). As I wrote above. The undetected disk error rate is not improving (AFAIK) as fast as disk size and data size that these drives are used for. Therefore the value of this protection is increasing all the time. Sure it's true that something else that could trash your data without checksumming can still trash your data with it. But making sure that the data gets unmangled if it can is still worth something, and the improvements you point out are needed in other components would be pointless (according to your argument) if something like ZFS didn't also exist. So depending upon ZFS's checksums to protect your data in most PC environments is sort of like leaving on a vacation and locking and bolting the back door of your house while leaving the front door wide open: yes, a burglar is less likely to enter by the back door, but thinking that the extra bolt there made you much safer is likely foolish. .. are you just trying to say that without multiple copies of data in multiple physical locations you're not really accomplishing a
Re: [zfs-discuss] Yager on ZFS
On Tue, 4 Dec 2007, Stefano Spinucci wrote: On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? if I missed something tell me, and I'll happily stay with linux with my data checksummed and snapshotted. bye --- Stefano Spinucci Hi Stefano, Did you get a *real* answer to your question? Do you think that this (quoted) message is a *real* answer? Hi, Al - I see that you're still having difficulty understanding basic English, and your other recent technical-content-free drivel here suggests that you might be better off considering a career in janitorial work than in anything requiring even basic analytical competence. But I remain willing to help you out with English until you can find the time to take a remedial course (though for help with finding a vocation more consonant with your abilities you'll have to look elsewhere). Let's begin by repeating the question at issue, since failing to understand that may be at the core of your problem: what *real* alternatives are you referring to??? Despite a similar misunderstanding by your equally-illiterate associate Mr. Cook, that was not a question about what alternatives provided the specific support in which Stefano was particularly interested (though in another part of my response to him I did attempt to help him understand why that interest might be misplaced). Rather, it was a question about what *I* had referred to in an earlier post of mine, as you might also have gleaned from the first sentence of my response to that question (As I said in the post to which you responded...) had what passes for your brain been even minimally engaged when you read it. My response to that question continued by listing some specific features (snapshots, disk scrubbing, software RAID) available in Linux and Free BSD that made them viable alternatives to ZFS for enterprise use (the context of that earlier post that I was being questioned about). Whether Linux and FreeBSD also offer management aids I admitted I didn't know - though given ZFS's own limitations in this area such as the need to define mirror pairs and parity groups explicitly and the inability to expand parity groups it's not clear that lack thereof would constitute a significant drawback (especially since the management activities that their file systems require are comparable to what such enterprise installations are already used to dealing with). And, in an attempt to forestall yet another round of babble, I then addressed the relative importance (or lack thereof) of several predictable Yes, but ZFS also offers wonderful feature X... responses. Now, not being a psychic myself, I can't state with authority that Stefano really meant to ask the question that he posed rather than something else. In retrospect, I suppose that some of his surrounding phrasing *might* suggest that he was attempting (however unskillfully) to twist my comment about other open source solutions being similarly enterprise-capable into a provably-false assertion that those other solutions offered the *same* features that he apparently considers so critical in ZFS rather than just comparably-useful ones. But that didn't cross my mind at the time: I simply answered the question that he asked, and in passing also pointed out that those features which he apparently considered so critical might well not be. Once again, though, I've reached the limit of my ability to dumb down the discussion in an attempt to reach your level: if you still can't grasp it, perhaps a friend will lend a hand. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Wed, 5 Dec 2007, can you guess? wrote: snip reformatted . Changing ZFS's approach to snapshots from block-oriented to audit-trail-oriented, in order to pave the way for a journaled rather than shadow-paged approach to transactional consistency (which then makes data redistribution easier to allow rebalancing across not only local disks but across multiple nodes using algorithmic rather than pointer-based placement) starts to get more into a 'raze it to the ground and start over' mode, though - leaving plenty of room for one or more extended postscripts to 'the last word in file systems'. - bill Beep; Beep; Beep, Beep, Beep, beep beep beep beep-beep-beep 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
Re: [zfs-discuss] Yager on ZFS
On Wed, 5 Dec 2007, Al Hopper wrote: On Wed, 5 Dec 2007, Eric Haycraft wrote: [... reformatted ] Why are we still feeding this troll? Paid trolls deserve no response and there is no value in continuing this thread. (And no guys, he isn't being paid by NetApp.. think bigger) The troll will continue to try to downplay features of zfs and the community will counter...and on and on. +1 - a troll Ques: does it matter why he's a troll? I don't think so but my best guess is that Bill is out of work, and, due to the financial hardship, has had to cut his alzheimer's medication dosage in half. I could be wrong, with my guess, but as long as I keep seeing this can you guess? question, I feel compelled to answer it. :) Please feel free to offer your best can you guess? answer! 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! :) Followup: Don't you hate it when you have to followup your own email! I forgot to include the reference info that backs up my best guess. Ref: http://www.alz.org/alzheimers_disease_what_is_alzheimers.asp Quote: Alzheimer's destroys brain cells, causing problems with memory, thinking and behavior severe enough to affect work, lifelong hobbies or social life. Alzheimer's gets worse over time, and it is fatal. Quote: Is the most common form of dementia, a general term for the loss of memory and other intellectual abilities serious enough to interfere with daily life. Quote: Just like the rest of our bodies, our brains change as we age. Most of us notice some slowed thinking and occasional problems remembering certain things. However, serious memory loss, confusion and other major changes in the way our minds work are not a normal part of aging. They may be a sign that brain cells are failing. 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
Re: [zfs-discuss] Yager on ZFS
Literacy has nothing to do with the glaringly obvious BS you keep spewing. Rather than answer a question, which couldn't be answered, because you were full of it, you tried to convince us all he really didn't know what he wanted. The assumption sure made an a$$ out of someone, but you should be used to painting yourself into a corner by now. There aren't free alternatives in linux or freebsd that do what zfs does, period. You can keep talking in circles till you're blue in the face, or I suppose your fingers go numb in this case, but the fact isn't going to change. Yes, people do want zfs for any number of reasons, that's why they're here. You would think the fact zfs was ported to freebsd so quickly would've been a good first indicator that the functionality wasn't already there. Then again, the glaringly obvious seems to consistently bypass you. I'm guessing it's because there's no space left in the room... your head is occupying any and all available. Nevermind, your ability to admit when you're wrong is only rivaled by your petty attempts at insults. If you'd like to answer stephans question, feel free. If all you can muster is a Microsoftesque you don't really know what you want, I suggest giving up now. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
I have budget constraints then I can use only user-level storage. until I discovered zfs I used subversion and git, but none of them is designe d to manage gigabytes of data, some to be versioned, some to be unversioned. I can't afford silent data corruption and, if the final response is *now* th ere is no *real* opensource software alternative to zfs automatic checksummin g and simple snapshotting I'll be an happy solaris user (for data storage), an happy linux user (for everyday work), and an unhappy offline windows user (for some video-related activity I can't do with linux). Note that I don't wish to argue for/against zfs/billtodd but the comment above about no *real* opensource software alternative zfs automating checksumming and simple snapshotting caught my eye. There is an open source alternative for archiving that works quite well. venti has been available for a few years now. It runs on *BSD, linux, macOS plan9 (its native os). It uses strong crypto checksums, stored separately from the data (stored in the pointer blocks) so you get a similar guarantee against silent data corruption as ZFS. You can back up a variety of filesystems (ufs, hfs, ext2fs, fat) or use it to to backup a file tree. Each backup results in a single 45 byte score containing the checksum of root pointer block. Using this score you can retrieve the entire backup. Further, it stores only one copy of a data block regardless of what files or which backup it may belong to. In effect every full backup is an incremental backup (only changed data blocks and changed or new ptr blocks are stored). So it is really an archival server. You don't take snapshots but you do a backup. However you can nfs mount a venti and all your backups will show up under directories like machine//mmdd/filesystem. Ideally you'd store a venti on RAID storage. You can even copy a bunch of venti to another one, you can store its arenas on CDs or DVD and so on. It is not as fast as ZFS nor anywhere near as easy to use and its intended use is not the same as ZFS (not a primary filesystem). But for what it does, it is not bad at all! Unlike ZFS, it fits best where you have a fast filesystem for speed critical use, venti for backups and RAID for redundancy. Google for venti sean dorward. If interested, go to http://swtch.com/plan9port/ and pick up plan9port (a collection of programs from plan9, not just venti). See ttp://swtch.com/plan9port/man/man8/index.html for how to use venti. thank you for the suggestion. after reading something about venti I like its features and its frugality (no fuss, no hype, only a reliable fs). however, having touched zfs before venti, I admit I like zfs more and furthermore this give me a reason to use opensolaris and maybe tomorrow dump linux entirely. I'd like to have time to play with plan9port and maybe also with inferno, but for now the descent can wait. I think for every fully digital people own data are vital, and almost everyon e would reply NONE at your question what level of risk user is willing to tolerate. NONE is not possible. It is a question of how much risk you are willing to tolerate for what cost. Thankfully, these days you have a variety of choices and much much lower cost for a given degree of risk compared to just a few years ago! I know no risk is impossible, but a checksumming fs with snapshots (mirrored on two disks used alternatively) is a good compromise for me (a professional-home user, with data I can't -or I'd like not to- loose). bye --- Stefano Spinucci This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
apologies in advance for prolonging this thread .. i had considered taking this completely offline, but thought of a few people at least who might find this discussion somewhat interesting .. at the least i haven't seen any mention of Merkle trees yet as the nerd in me yearns for On Dec 5, 2007, at 19:42, bill todd - aka can you guess? wrote: what are you terming as ZFS' incremental risk reduction? .. (seems like a leading statement toward a particular assumption) Primarily its checksumming features, since other open source solutions support simple disk scrubbing (which given its ability to catch most deteriorating disk sectors before they become unreadable probably has a greater effect on reliability than checksums in any environment where the hardware hasn't been slapped together so sloppily that connections are flaky). ah .. okay - at first reading incremental risk reduction seems to imply an incomplete approach to risk .. putting various creators and marketing organizations pride issues aside for a moment, as a complete risk reduction - nor should it billed as such. However i do believe that an interesting use of the merkle tree with a sha256 hash is somewhat of an improvement over conventional volume based data scrubbing techniques since there can be a unique integration between the hash tree for the filesystem block layout and a hierarchical data validation method. In addition to the finding unknown areas with the scrub, you're also doing relatively inexpensive data validation checks on every read. Aside from the problems that scrubbing handles (and you need scrubbing even if you have checksums, because scrubbing is what helps you *avoid* data loss rather than just discover it after it's too late to do anything about it), and aside from problems deriving from sloppy assembly (which tend to become obvious fairly quickly, though it's certainly possible for some to be more subtle), checksums primarily catch things like bugs in storage firmware and otherwise undetected disk read errors (which occur orders of magnitude less frequently than uncorrectable read errors). sure - we've seen many transport errors, as well as firmware implementation errors .. in fact with many arrays we've seen data corruption issues with the scrub (particularly if the checksum is singly stored along with the data block) - just like spam you really want to eliminate false positives that could indicate corruption where there isn't any. if you take some time to read the on disk format for ZFS you'll see that there's a tradeoff that's done in favor of storing more checksums in many different areas instead of making more room for direct block pointers. Robert Milkowski cited some sobering evidence that mid-range arrays may have non-negligible firmware problems that ZFS could often catch, but a) those are hardly 'consumer' products (to address that sub-thread, which I think is what applies in Stefano's case) and b) ZFS's claimed attraction for higher-end (corporate) use is its ability to *eliminate* the need for such products (hence its ability to catch their bugs would not apply - though I can understand why people who needed to use them anyway might like to have ZFS's integrity checks along for the ride, especially when using less-than-fully-mature firmware). actually on this list we've seen a number of consumer level products including sata controllers, and raid cards (which are also becoming more commonplace in the consumer realm) that can be confirmed to throw data errors. Code maturity issues aside, there aren't very many array vendors that are open-sourcing their array firmware - and if you consider zfs as a feature-set that could function as a multi- purpose storage array (systems are cheap) - i find it refreshing that everything that's being done under the covers is really out in the open. And otherwise undetected disk errors occur with negligible frequency compared with software errors that can silently trash your data in ZFS cache or in application buffers (especially in PC environments: enterprise software at least tends to be more stable and more carefully controlled - not to mention their typical use of ECC RAM). So depending upon ZFS's checksums to protect your data in most PC environments is sort of like leaving on a vacation and locking and bolting the back door of your house while leaving the front door wide open: yes, a burglar is less likely to enter by the back door, but thinking that the extra bolt there made you much safer is likely foolish. granted - it's not an all-in-one solution, but by combining the merkle tree approach with the sha256 checksum along with periodic data scrubbing - it's a darn good approach .. particularly since it also tends to cost a lot less than what you might have to pay elsewhere for something you
Re: [zfs-discuss] Yager on ZFS
what are you terming as ZFS' incremental risk reduction? I'm not Bill, but I'll try to explain. Compare a system using ZFS to one using another file system -- say, UFS, XFS, or ext3. Consider which situations may lead to data loss in each case, and the probability of each such situation. The difference between those two sets is the 'incremental risk reduction' provided by ZFS. So, for instance, assuming you're using ZFS RAID in the first case, and a traditional RAID implementation in the second case: * Single-disk failure == same probability of occurrence, no data loss in either case. * Double-disk failure == same probability of occurrence, no data loss in either case (assuming RAID6/RAIDZ2; or data loss assuming RAID5/RAIDZ) * Uncorrectable read error == same probability of occurrence, no data loss in either case * Single-bit error on the wire == same, no data loss in either case * Multi-bit error on the wire, detected by CRC == same, no data loss * Multi-bit error on the wire == This is the first interesting case (since it differs). This is a case where ZFS will correct the error, and the standard RAID will not. The probability of occurrence is hard to compute, since it depends on the distribution of bit errors on the wire, which aren't really independent. Roughly, though, since the wire transfers usually use a 32-bit CRC, the probability of an undetected error is 2^-32, or 0.000 000 023 2%. [You could ask whether this is true for real data. It appears to be; see Performance of Checksums and CRCs over Real Data by Stone, Greenwald, Partridge Hughes. ] * Error in the file system code == Another interesting case, but we don't have sufficient data to gauge probabilities. * Undetected error in host memory == same probability of occurrence, same data loss. * Undetected error in RAID memory == same probability, but data loss in non-ZFS case. We can estimate the probability of this, but I don't have current data. Single-bit errors were measured at a rate of 2*10^-12 on a number of systems in the mid-1990s (see Single Event Upset at Ground Level by Eugene Normand). If the bits are separated spatially (as is normally done), the probability of a double-bit error is roughly 4*10^-24, and of a triple-bit error, 8*10^-36. So an undetected error is very, VERY unlikely, at least from RAM cell effects. But ZFS can correct it, if it happens. * Failure of facility (e.g. fire, flood, power surge) == same/total loss of data. [ Total loss if you don't have a backup, of course. ] ... go on as desired. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Now, not being a psychic myself, I can't state with authority that Stefano really meant to ask the question that he posed rather than something else. In retrospect, I suppose that some of his surrounding phrasing *might* suggest that he was attempting (however unskillfully) to twist my comment about other open source solutions being similarly enterprise-capable into a provably-false assertion that those other solutions offered the *same* features that he apparently considers so critical in ZFS rather than just comparably-useful ones. But that didn't cross my mind at the time: I simply answered the question that he asked, and in passing also pointed out that those features which he apparently considered so critical might well not be. dear bill, my question was honest and, as I stated before: I'm a linux user who discovered zfs and 'd like to use it to store (versioned and checksummed) valuable data. then, if there are no alternatives to zfs, I'd gladly stick with it, and unless you have a *better* solution (repeat with me: important data, 1 laptop, three disks), please don't use further my name for your guessing of an hidden plot to discover the (evident) bias of your messages. thanks --- Stefano Spinucci This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Dec 6, 2007, at 00:03, Anton B. Rang wrote: what are you terming as ZFS' incremental risk reduction? I'm not Bill, but I'll try to explain. Compare a system using ZFS to one using another file system -- say, UFS, XFS, or ext3. Consider which situations may lead to data loss in each case, and the probability of each such situation. The difference between those two sets is the 'incremental risk reduction' provided by ZFS. ah .. thanks Anton - so the next step would be to calculate the probability of occurrence, the impact to operation, and the return to service for each anticipated risk in a given environment in order to determine the size of the increment that constitutes the risk reduction that ZFS is providing. Without this there's just a lot of hot air blowing around in here .. snip excellent summary of risks - perhaps we should also consider the availability and transparency of the code to potentially mitigate future problems .. that's currently where i'm starting to see tremendous value in open and free raid controller solutions to help drive down the cost of implementation for this sort of data protection instead of paying through the nose for a closed hardware based solutions (which is still a great margin in licensing for dedicated storage vendors) --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Literacy has nothing to do with the glaringly obvious BS you keep spewing. Actually, it's central to the issue: if you were capable of understanding what I've been talking about (or at least sufficiently humble to recognize the depths of your ignorance), you'd stop polluting this forum with posts lacking any technical content whatsoever. Rather than answer a question, which couldn't be answered, The question that was asked was answered - it's hardly my problem if you could not competently parse the question, or the answer, or the subsequent explanation (though your continuing drivel after those three strikes suggests that you may simply be ineducable). because you were full of it, you tried to convince us all he really didn't know what he wanted. No: I answered his question and *also* observed that he probably really didn't know what he wanted (at least insofar as being able to *justify* the intensity of his desire for it). ... There aren't free alternatives in linux or freebsd that do what zfs does, period. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). You can keep talking in circles till you're blue in the face, or I suppose your fingers go numb in this case, but the fact isn't going to change. Yes, people do want zfs for any number of reasons, that's why they're here. Indeed, but it has become obvious that most of the reasons are non-technical in nature. This place is fanboy heaven, where never is heard a discouraging word (and you're hip-deep in buffalo sh!t). Hell, I came here myself 18 months ago because ZFS seemed interesting, but found out that the closer I looked, the less interesting it got. Perhaps it's not surprising that so many of you never took that second step: it does require actual technical insight, which seems to be in extremely short supply here. So short that it's not worth spending time here from any technical standpoint: at this point I'm mostly here for the entertainment, and even that is starting to get a little tedious. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Actually, it's central to the issue: if you were capable of understanding what I've been talking about (or at least sufficiently humble to recognize the depths of your ignorance), you'd stop polluting this forum with posts lacking any technical content whatsoever. I don't speak full of myself, apparently nobody else here does either, because nobody has a clue what you continue to ramble about. The question that was asked was answered - it's hardly my problem if you could not competently parse the question, or the answer, or the subsequent explanation (though your continuing drivel after those three strikes suggests that you may simply be ineducable). Except nobody but you seems to be able to acertain any sort of answer from your rambling response. The question was simple, as would an adequate answer. You either aren't literate enough to understand the question, or you're wrong. It's clearly the latter. No: I answered his question and *also* observed that he probably really didn't know what he wanted (at least insofar as being able to *justify* the intensity of his desire for it). Funny, the original poster, and everyone else disagrees with you. But with such visions of granduer, I suppose we're all just wrong. No one said that there were: the real issue is that there's not much reason to care, since the available solutions don't need to be *identical* to offer *comparable* value (i.e., they each have different strengths and weaknesses and the net result yields no clear winner - much as some of you would like to believe otherwise). Right, so yet again, you were wrong. Stop telling us what you think we need. Stop trying to impose your arrogant ASSumptions onto us. WE don't care what YOU think WE need. Indeed, but it has become obvious that most of the reasons are non-technical in nature. This place is fanboy heaven, where never is heard a discouraging word (and you're hip-deep in buffalo sh!t). There you go. You heard it here first folks. Anyone who doesn't agree with bill is a fanboy. Hell, I came here myself 18 months ago because ZFS seemed interesting, but found out that the closer I looked, the less interesting it got. Perhaps it's not surprising that so many of you never took that second step: it does require actual technical insight, which seems to be in extremely short supply here. So leave. So short that it's not worth spending time here from any technical standpoint: at this point I'm mostly here for the entertainment, and even that is starting to get a little tedious. - bill Oh bill, I think we both know your ego won't be able to stop without being banned or getting the *last word*. Unfortunately you bring nothing to the table but arrogance, which hasn't, and isn't getting you very far. Keep up the good work though. Are you getting paid by word count, or by post? I'm guessing word count given the long winded content void responses. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Now, not being a psychic myself, I can't state with authority that Stefano really meant to ask the question that he posed rather than something else. In retrospect, I suppose that some of his surrounding phrasing *might* suggest that he was attempting (however unskillfully) to twist my comment about other open source solutions being similarly enterprise-capable into a provably-false assertion that those other solutions offered the *same* features that he apparently considers so critical in ZFS rather than just comparably-useful ones. But that didn't cross my mind at the time: I simply answered the question that he asked, and in passing also pointed out that those features which he apparently considered so critical might well not be. dear bill, my question was honest That's how I originally accepted it, and I wouldn't have revisited the issue looking for other interpretations if two people hadn't obviously thought it meant something else. For that matter, even if you actually intended it to mean something else that doesn't imply that there was any devious intent. In any event, what you actually asked was what I had referred to, and I told you: it may not have met your personal goals for your own storage, but that wasn't relevant to the question that you asked (and that I answered). Your English is so good that the possibility that it might be a second language had not occurred to me - but if so it would help explain any subtle miscommunication. ... if there are no alternatives to zfs, As I explained, there are eminently acceptable alternatives to ZFS from any objective standpoint. I'd gladly stick with it, And you're welcome to, without any argument from me - unless you try to convince other people that there are strong technical reasons to do so, in which case I'll challenge you to justify them in detail so that any hidden assumptions can be brought out into the open. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
I suppose we're all just wrong. By George, you've got it! - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Your response here appears to refer to a different post in this thread. I never said I was a typical consumer. Then it's unclear how your comment related to the material which you quoted (and hence to which it was apparently responding). If you look around photo forums, you'll see an interest the digital workflow which includes long term storage and archiving. A chunk of these users will opt for an external RAID box (10%? 20%?). I suspect ZFS will change that game in the future. In particular for someone doing lots of editing, snapshots can help recover from user error. Ah - so now the rationalization has changed to snapshot support. Unfortunately for ZFS, snapshot support is pretty commonly available (e.g., in Linux's LVM - and IIRC BSD's as well - if you're looking at open-source solutions) so anyone who actually found this feature important has had access to it for quite a while already. And my original comment which you quoted still obtains as far as typical consumers are concerned. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? if I missed something tell me, and I'll happily stay with linux with my data checksummed and snapshotted. bye --- Stefano Spinucci This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 11/7/07, can you guess? [EMAIL PROTECTED] wrote: However, ZFS is not the *only* open-source approach which may allow that to happen, so the real question becomes just how it compares with equally inexpensive current and potential alternatives (and that would make for an interesting discussion that I'm not sure I have time to initiate tonight). - bill Hi bill, only a question: I'm an ex linux user migrated to solaris for zfs and its checksumming; So the question is: do you really need that feature (please quantify that need if you think you do), or do you just like it because it makes you feel all warm and safe? Warm and safe is definitely a nice feeling, of course, but out in the real world of corporate purchasing it's just one feature out of many 'nice to haves' - and not necessarily the most important. In particular, if the *actual* risk reduction turns out to be relatively minor, that nice 'feeling' doesn't carry all that much weight. you say there are other open-source alternatives but, for a linux end user, I'm aware only of Oracle btrfs (http://oss.oracle.com/projects/btrfs/), who is a Checksumming Copy on Write Filesystem not in a final state. what *real* alternatives are you referring to??? As I said in the post to which you responded, I consider ZFS's ease of management to be more important (given that even in high-end installations storage management costs dwarf storage equipment costs) than its real but relatively marginal reliability edge, and that's the context in which I made my comment about alternatives (though even there if ZFS continues to require definition of mirror pairs and parity groups for redundancy that reduces its ease-of-management edge, as does its limitation to a single host system in terms of ease-of-scaling). Specifically, features like snapshots, disk scrubbing (to improve reliability by dramatically reducing the likelihood of encountering an unreadable sector during a RAID rebuild), and software RAID (to reduce hardware costs) have been available for some time in Linux and FreeBSD, and canned management aids would not be difficult to develop if they don't exist already. The dreaded 'write hole' in software RAID is a relatively minor exposure (since it only compromises data if a system crash or UPS failure - both rare events in an enterprise setting - sneaks in between a data write and the corresponding parity update and then, before the array has restored parity consistency in the background, a disk dies) - and that exposure can be reduced to seconds by a minuscule amount of NVRAM that remembers which writes were active (or to zero with somewhat more NVRAM to remember the updates themselves in an inexpensive hardware solution). The real question is usually what level of risk an enterprise storage user is willing to tolerate. At the paranoid end of the scale reside the users who will accept nothing less than z-series or Tandem-/Stratus-style end-to-end hardware checking from the processor traces on out - which rules out most environments that ZFS runs in (unless Sun's N-series telco products might fill the bill: I'm not very familiar with them). And once you get down into users of commodity processors, the risk level of using stable and robust file systems that lack ZFS's additional integrity checks is comparable to the risk inherent in the rest of the system (at least if the systems are carefully constructed, which should be a given in an enterprise setting) - so other open-source solutions are definitely in play there. All things being equal, of course users would opt for even marginally higher reliability - but all things are never equal. If using ZFS would require changing platforms or changing code, that's almost certainly a show-stopper for enterprise users. If using ZFS would compromise performance or require changes in management practices (e.g., to accommodate file-system-level quotas), those are at least significant impediments. In other words, ZFS has its pluses and minuses just as other open-source file systems do, and they *all* have the potential to start edging out expensive proprietary solutions in *some* applications (and in fact have already started to do so). When we move from 'current' to 'potential' alternatives, the scope for competition widens. Because it's certainly possible to create a file system that has all of ZFS's added reliability but runs faster, scales better, incorporates additional useful features, and is easier to manage. That discussion is the one that would take a lot of time to delve into adequately (and might be considered off topic for this forum - which is why I've tried to concentrate here on improvements that ZFS could actually incorporate without turning it upside down). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list
Re: [zfs-discuss] Yager on ZFS
I never said I was a typical consumer. After all, I bought a $1600 DSLR. If you look around photo forums, you'll see an interest the digital workflow which includes long term storage and archiving. A chunk of these users will opt for an external RAID box (10%? 20%?). I suspect ZFS will change that game in the future. In particular for someone doing lots of editing, snapshots can help recover from user error. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
[Zombie thread returns from the grave...] Getting back to 'consumer' use for a moment, though, given that something like 90% of consumers entrust their PC data to the tender mercies of Windows, and a large percentage of those neither back up their data, nor use RAID to guard against media failures, nor protect it effectively from the perils of Internet infection, it would seem difficult to assert that whatever additional protection ZFS may provide would make any noticeable difference in the consumer space - and that was the kind of reasoning behind my comment that began this sub-discussion. As a consumer at home, IT guy at work and amateur photographer, I think ZFS will help change that. Let's see, now: Consumer at home? OK so far. IT guy at work? Nope, nothing like a mainstream consumer, who doesn't want to know about anything like the level of detail under discussion here. Amateur photographer? Well, sort of - except that you seem to be claiming to have reached the *final* stage of evolution that you lay out below, which - again - tends to place you *well* out of the mainstream. Try reading my paragraph above again and seeing just how closely it applies to people like you. Here's what I think photogs evolve through: ) What are negatives? - Mom/dad taking holiday photos 2) Keep negatives in the envelope - average snapshot photog 3) Keep them filed in boxes - started snapping with a SLR? Might be doing darkroom work 4) Get acid free boxes - pro/am. 5) Store slides in archival environment (humidity, temp, etc). - obsessive In the digital world: 1) keeps them on the card until printed. Only keeps the print 2) copies them to disk erases them off the card. Gets burned when system disk dies 2a) puts them on CD/DVD. Gets burned a little when the disk dies and some photos not on CD/DVDs yet. OK so far. My wife is an amateur photographer and that's the stage where she's at. Her parents, however, are both retired *professional* photographers - and that's where they're at as well. 3a) gets an external USB drive to store things. Gets burned when that disk dies. That sounds as if it should have been called '2b' rather than '3a', since there's still only one copy of the data. 3b) run raid in the box. 3c) gets an external RAID disk (buffalo/ReadyNAS, etc). While these (finally) give you some redundancy, they don't protect against loss due to user errors, system errors, or virii (well, an external NAS might help some with the last two, but not a simple external RAID). They also cost significantly more (and are considerably less accessible to the average consumer) than simply keeping a live copy on your system plus an archive copy (better yet, *two* archive copies) on DVDs (the latter is what my wife and her folks do for any photos they care about). 4) archives to multiple places. etc... At which point you find out that you didn't need RAID after all (see above): you just leave the photos on a flash card (which are dirt-cheap these days) and your system disk until they've been copied to the archive media. 5) gets ZFS and does transfer direct to local disk from flash card. Which doesn't give you any data redundancy at all unless you're using multiple drives (guess how many typical consumers do) and doesn't protect you from user errors, system errors, or virii (unless you use an external NAS to help with the last two - again, guess how many typical consumers do) - and you'd *still* arguably be better off using the approach I described in my previous paragraph (since there's nothing like off-site storage if you want *real* protection). In other words, you can't even make the ZFS case for the final-stage semi-professional photographer above, let alone anything remotely resembling a 'consumer': you'd just really, really like to justify something that you've become convinced is hot. There's obviously been some highly-effective viral marketing at work here. Today I can build a Solaris file server for a reasonable price with off the shelf parts ($300 + disks). *Build* a file server? You must be joking: if a typical consumer wants to *buy* a file server they can do so (though I'm not sure that a large percentage of 'typical' consumers actually *have* done so) - but expecting them to go out and shop for one running ZFS is - well, 'hopelessly naive' doesn't begin to do the idea justice. I can't get near that for a WAFL based system. Please don't try to reintroduce WAFL into the consumer part of this discussion: I though we'd finally succeeded in separating the sub-threads. ... I can see ZFS coming to ready made networked RAID box that a pro-am photographer could purchase. *If* s/he had any interest in ZFS per se - see above. I don't ever see that with WAFL. And either FS on a network RAID box will be less error prone then a box running ext3/xfs as is typical now. 'Less error
Re: [zfs-discuss] Yager on ZFS
Getting back to 'consumer' use for a moment, though, given that something like 90% of consumers entrust their PC data to the tender mercies of Windows, and a large percentage of those neither back up their data, nor use RAID to guard against media failures, nor protect it effectively from the perils of Internet infection, it would seem difficult to assert that whatever additional protection ZFS may provide would make any noticeable difference in the consumer space - and that was the kind of reasoning behind my comment that began this sub-discussion. As a consumer at home, IT guy at work and amateur photographer, I think ZFS will help change that.Here's what I think photogs evolve through: 1) What are negatives? - Mom/dad taking holiday photos 2) Keep negatives in the envelope - average snapshot photog 3) Keep them filed in boxes - started snapping with a SLR? Might be doing darkroom work 4) Get acid free boxes - pro/am. 5) Store slides in archival environment (humidity, temp, etc). - obsessive In the digital world: 1) keeps them on the card until printed. Only keeps the print 2) copies them to disk erases them off the card. Gets burned when system disk dies 2a) puts them on CD/DVD. Gets burned a little when the disk dies and some photos not on CD/DVDs yet. 3a) gets an external USB drive to store things. Gets burned when that disk dies. 3b) run raid in the box. 3c) gets an external RAID disk (buffalo/ReadyNAS, etc). 4) archives to multiple places. etc... 5) gets ZFS and does transfer direct to local disk from flash card. Today I can build a Solaris file server for a reasonable price with off the shelf parts ($300 + disks). I can't get near that for a WAFL based system. The only WAFL I can get is only on networked storage which fails 5) for the obsessed. I can see ZFS coming to ready made networked RAID box that a pro-am photographer could purchase. I don't ever see that with WAFL. And either FS on a network RAID box will be less error prone then a box running ext3/xfs as is typical now. And that's what the ZFS hype is about IMO. As for a the viability of buying one of the boxes, look at what a pro-am photographer might buy. I bought a Nikon D100 for $1600 when it came up. A new lens for $500 and I'm interested in $1000 lenses. Tripod, flash, etc. I spent lots of $$ to capture the images. I'll spend similar to keep them. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 29-Nov-07, at 2:48 PM, Tom Buskey wrote: Getting back to 'consumer' use for a moment, though, given that something like 90% of consumers entrust their PC data to the tender mercies of Windows, and a large percentage of those neither back up their data, nor use RAID to guard against media failures, nor protect it effectively from the perils of Internet infection, it would seem difficult to assert that whatever additional protection ZFS may provide would make any noticeable difference in the consumer space - and that was the kind of reasoning behind my comment that began this sub-discussion. As a consumer at home, IT guy at work and amateur photographer, I think ZFS will help change that. ... 5) gets ZFS and does transfer direct to local disk from flash card. Today I can build a Solaris file server for a reasonable price with off the shelf parts ($300 + disks). I can't get near that for a WAFL based system. The only WAFL I can get is only on networked storage which fails 5) for the obsessed. I can see ZFS coming to ready made networked RAID box that a pro-am photographer could purchase. Xserve + Xserve RAID... ZFS is already in OS X 10.5. As easy to set up and administer as any OS X system; a problem free and FAST network server to Macs or PCs. http://www.apple.com/xserve/ --Toby I don't ever see that with WAFL. And either FS on a network RAID box will be less error prone then a box running ext3/xfs as is typical now. And that's what the ZFS hype is about IMO. As for a the viability of buying one of the boxes, look at what a pro-am photographer might buy. ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 11/29/07, Toby Thain [EMAIL PROTECTED] wrote: Xserve + Xserve RAID... ZFS is already in OS X 10.5. As easy to set up and administer as any OS X system; a problem free and FAST network server to Macs or PCs. That is a great theory ... we have a number of Xserves with Xraids. No ZFS on Mac OS X (yet), so we are running HFS+. The problem is that HFS+ is such a pig that some backups never functional complete (one server has about 4-5 TB and millions of files, not the large media files that HFS+ seems to be optimized for). About 18 months ago we had a scheduled server room power outage. We brought everything down cleanly. On bringing it back up the volume from the Xraid was corrupt. Apple's only answer (after much analysis) was to reload from backup. Thankfully this was not the server with the millions of files, but one that we did have good backups of. We have been terrified every time we have had to restart the server with the millions of files. Not technology that I would want to trust my photos to, at least until there are better recovery tools out there. But then again, I have a similar issue with ZFS. So far there haven't been enough odd failures to cause real recovery tools to be written. Eventually there will be tools to reconstruct as much of the metadata as possible after a disaster (there always are for true Enterprise systems), but not yet. -- Paul Kraus Albacon 2008 Facilities ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 29-Nov-07, at 4:09 PM, Paul Kraus wrote: On 11/29/07, Toby Thain [EMAIL PROTECTED] wrote: Xserve + Xserve RAID... ZFS is already in OS X 10.5. As easy to set up and administer as any OS X system; a problem free and FAST network server to Macs or PCs. That is a great theory ... we have a number of Xserves with Xraids. No ZFS on Mac OS X (yet), 10.5. so we are running HFS+. The problem is that HFS+ is such a pig that some backups never functional complete (one server has about 4-5 TB and millions of files, not the large media files that HFS+ seems to be optimized for). You might also enjoy some of the alternative Xserve configurations described at http://alienraid.org/ I would not expect to see such scaling issues with Linux on Xserve, for example. About 18 months ago we had a scheduled server room power outage. We brought everything down cleanly. On bringing it back up the volume from the Xraid was corrupt. Apple's only answer (after much analysis) was to reload from backup. Thankfully this was not the server with the millions of files, but one that we did have good backups of. We have been terrified every time we have had to restart the server with the millions of files. Not technology that I would want to trust my photos to, at least until there are better recovery tools out there. But then again, I have a similar issue with ZFS. So far there haven't been enough odd failures to cause real recovery tools to be written. Recovery != backup. Eventually there will be tools to reconstruct as much of the metadata as possible after a disaster (there always are for true Enterprise systems), but not yet. Sounds like you have answered all your questions about ZFS already. --Toby -- Paul Kraus Albacon 2008 Facilities ___ 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
Re: [zfs-discuss] Yager on ZFS
On 11/29/07, Toby Thain [EMAIL PROTECTED] wrote: That is a great theory ... we have a number of Xserves with Xraids. No ZFS on Mac OS X (yet), 10.5. Last I looked they were only supporting read only ZFS under 10.5. Also, based on the experiences of a number of my coworkers, 10.5 is nowhere near ready for real production use. Eventually there will be tools to reconstruct as much of the metadata as possible after a disaster (there always are for true Enterprise systems), but not yet. Sounds like you have answered all your questions about ZFS already. Yup. My comment was more about MacOSX, Xserve, and Xraid suitability in situations where reliability is key than ZFS. -- Paul Kraus Albacon 2008 Facilities ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On Thu, Nov 08, 2007 at 07:28:47PM -0800, can you guess? wrote: How so? In my opinion, it seems like a cure for the brain damage of RAID-5. Nope. A decent RAID-5 hardware implementation has no 'write hole' to worry about, and one can make a software implementation similarly robust with some effort (e.g., by using a transaction log to protect the data-plus-parity double-update or by using COW mechanisms like ZFS's in a more intelligent manner). Can you reference a software RAID implementation which implements a solution to the write hole and performs well. My understanding (and this is based on what I've been told from people more knowledgeable in this domain than I) is that software RAID has suffered from being unable to provide both correctness and acceptable performance. The part of RAID-Z that's brain-damaged is its concurrent-small-to-medium-sized-access performance (at least up to request sizes equal to the largest block size that ZFS supports, and arguably somewhat beyond that): while conventional RAID-5 can satisfy N+1 small-to-medium read accesses or (N+1)/2 small-to-medium write accesses in parallel (though the latter also take an extra rev to complete), RAID-Z can satisfy only one small-to-medium access request at a time (well, plus a smidge for read accesses if it doesn't verity the parity) - effectively providing RAID-3-style performance. Brain damage seems a bit of an alarmist label. While you're certainly right that for a given block we do need to access all disks in the given stripe, it seems like a rather quaint argument: aren't most environments that matter trying to avoid waiting for the disk at all? Intelligent prefetch and large caches -- I'd argue -- are far more important for performance these days. The easiest way to fix ZFS's deficiency in this area would probably be to map each group of N blocks in a file as a stripe with its own parity - which would have the added benefit of removing any need to handle parity groups at the disk level (this would, incidentally, not be a bad idea to use for mirroring as well, if my impression is correct that there's a remnant of LVM-style internal management there). While this wouldn't allow use of parity RAID for very small files, in most installations they really don't occupy much space compared to that used by large files so this should not constitute a significant drawback. I don't really think this would be feasible given how ZFS is stratified today, but go ahead and prove me wrong: here are the instructions for bringing over a copy of the source code: http://www.opensolaris.org/os/community/tools/scm - ahl -- Adam Leventhal, FishWorkshttp://blogs.sun.com/ahl ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Brain damage seems a bit of an alarmist label. While you're certainly right that for a given block we do need to access all disks in the given stripe, it seems like a rather quaint argument: aren't most environments that matter trying to avoid waiting for the disk at all? Intelligent prefetch and large caches -- I'd argue -- are far more important for performance these days. The concurrent small-i/o problem is fundamental though. If you have an application where you care only about random concurrent reads for example, you would not want to use raidz/raidz2 currently. No amount of smartness in the application gets around this. It *is* a relevant shortcoming of raidz/raidz2 compared to raid5/raid6, even if in many cases it is not significant. If disk space is not an issue, striping across mirrors will be okay for random seeks. But if you also care about diskspace, it's a show stopper unless you can throw money at the problem. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: This is a digitally signed message part. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? billtodd at metrocast.net writes: You really ought to read a post before responding to it: the CERN study did encounter bad RAM (and my post mentioned that) - but ZFS usually can't do a damn thing about bad RAM, because errors tend to arise either before ZFS ever gets the data or after it has already returned and checked it (and in both cases, ZFS will think that everything's just fine). According to the memtest86 author, corruption most often occurs at the moment memory cells are written to, by causing bitflips in adjacent cells. So when a disk DMA data to RAM, and corruption occur when the DMA operation writes to the memory cells, and then ZFS verifies the checksum, then it will detect the corruption. Therefore ZFS is perfectly capable (and even likely) to detect memory corruption during simple read operations from a ZFS pool. Of course there are other cases where neither ZFS nor any other checksumming filesystem is capable of detecting anything (e.g. the sequence of events: data is corrupted, checksummed, written to disk). Indeed - the latter was the first of the two scenarios that I sketched out. But at least on the read end of things ZFS should have a good chance of catching errors due to marginal RAM. That must mean that most of the worrisome alpha-particle problems of yore have finally been put to rest (since they'd be similarly likely to trash data on the read side after ZFS had verified it). I think I remember reading that somewhere at some point, but I'd never gotten around to reading that far in the admirably-detailed documentation that accompanies memtest: thanks for enlightening me. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Hello can, Thursday, November 15, 2007, 2:54:21 AM, you wrote: cyg The major difference between ZFS and WAFL in this regard is that cyg ZFS batch-writes-back its data to disk without first aggregating cyg it in NVRAM (a subsidiary difference is that ZFS maintains a cyg small-update log which WAFL's use of NVRAM makes unnecessary). cyg Decoupling the implementation from NVRAM makes ZFS usable on cyg arbitrary rather than specialized platforms, and that without cyg doubt constitutes a significant advantage by increasing the cyg available options (in both platform and price) for those cyg installations that require the kind of protection (and ease of cyg management) that both WAFL and ZFS offer and that don't require cyg the level of performance that WAFL provides and ZFS often may not cyg (the latter hasn't gotten much air time here, and while it can be cyg discussed to some degree in the abstract a better approach would cyg be to have some impartial benchmarks to look at, because the cyg on-disk block layouts do differ significantly and sometimes cyg subtly even if the underlying approaches don't). Well, ZFS allows you to put its ZIL on a separate device which could be NVRAM. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 11/15/07 9:05 AM, Robert Milkowski [EMAIL PROTECTED] wrote: Hello can, Thursday, November 15, 2007, 2:54:21 AM, you wrote: cyg The major difference between ZFS and WAFL in this regard is that cyg ZFS batch-writes-back its data to disk without first aggregating cyg it in NVRAM (a subsidiary difference is that ZFS maintains a cyg small-update log which WAFL's use of NVRAM makes unnecessary). cyg Decoupling the implementation from NVRAM makes ZFS usable on cyg arbitrary rather than specialized platforms, and that without cyg doubt constitutes a significant advantage by increasing the cyg available options (in both platform and price) for those cyg installations that require the kind of protection (and ease of cyg management) that both WAFL and ZFS offer and that don't require cyg the level of performance that WAFL provides and ZFS often may not cyg (the latter hasn't gotten much air time here, and while it can be cyg discussed to some degree in the abstract a better approach would cyg be to have some impartial benchmarks to look at, because the cyg on-disk block layouts do differ significantly and sometimes cyg subtly even if the underlying approaches don't). Well, ZFS allows you to put its ZIL on a separate device which could be NVRAM. Like RAMSAN SSD http://www.superssd.com/products/ramsan-300/ It is the only FC attached, Battery-backed SSD that I know of, and we have dreams of clusterfication. Otherwise we would use one of those PCI-Express based NVRAM cards that are on the horizon. My initial results for lots of small files was very pleasing. I dream of a JBOD with lots of disks + something like this built into 3u. Too bad Sun's forthcoming JBODS probably wont have anything similar to this... -Andy ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
... Well, ZFS allows you to put its ZIL on a separate device which could be NVRAM. And that's a GOOD thing (especially because it's optional rather than requiring that special hardware be present). But if I understand the ZIL correctly not as effective as using NVRAM as a more general kind of log for a wider range of data sizes and types, as WAFL does. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
Adam Leventhal wrote: On Thu, Nov 08, 2007 at 07:28:47PM -0800, can you guess? wrote: How so? In my opinion, it seems like a cure for the brain damage of RAID-5. Nope. A decent RAID-5 hardware implementation has no 'write hole' to worry about, and one can make a software implementation similarly robust with some effort (e.g., by using a transaction log to protect the data-plus-parity double-update or by using COW mechanisms like ZFS's in a more intelligent manner). Can you reference a software RAID implementation which implements a solution to the write hole and performs well. 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). ... The part of RAID-Z that's brain-damaged is its concurrent-small-to-medium-sized-access performance (at least up to request sizes equal to the largest block size that ZFS supports, and arguably somewhat beyond that): while conventional RAID-5 can satisfy N+1 small-to-medium read accesses or (N+1)/2 small-to-medium write accesses in parallel (though the latter also take an extra rev to complete), RAID-Z can satisfy only one small-to-medium access request at a time (well, plus a smidge for read accesses if it doesn't verity the parity) - effectively providing RAID-3-style performance. Brain damage seems a bit of an alarmist label. I consider 'brain damage' to be if anything a charitable characterization. While you're certainly right that for a given block we do need to access all disks in the given stripe, it seems like a rather quaint argument: aren't most environments that matter trying to avoid waiting for the disk at all? Everyone tries to avoid waiting for the disk at all. Remarkably few succeed very well. Intelligent prefetch and large caches -- I'd argue -- are far more important for performance these days. Intelligent prefetch doesn't do squat if your problem is disk throughput (which in server environments it frequently is). And all caching does (if you're lucky and your workload benefits much at all from caching) is improve your system throughput at the point where you hit the disk throughput wall. Improving your disk utilization, by contrast, pushes back that wall. And as I just observed in another thread, not by 20% or 50% but potentially by around two decimal orders of magnitude if you compare the sequential scan performance to multiple randomly-updated database tables between a moderately coarsely-chunked conventional RAID and a fine-grained ZFS block size (e.g., the 16 KB used by the example database) with each block sprayed across several disks. Sure, that's a worst-case scenario. But two orders of magnitude is a hell of a lot, even if it doesn't happen often - and suggests that in more typical cases you're still likely leaving a considerable amount of performance on the table even if that amount is a lot less than a factor of 100. The easiest way to fix ZFS's deficiency in this area would probably be to map each group of N blocks in a file as a stripe with its own parity - which would have the added benefit of removing any need to handle parity groups at the disk level (this would, incidentally, not be a bad idea to use for mirroring as well, if my impression is correct that there's a remnant of LVM-style internal management there). While this wouldn't allow use of parity RAID for very small files, in most installations they really don't occupy much space compared to that used by large files so this should not constitute a significant drawback. I don't really think this would be feasible given how ZFS is stratified today, but go ahead and prove me wrong: here are the instructions for bringing over a copy of the source code: http://www.opensolaris.org/os/community/tools/scm Now you want me not only to design the fix but code it for you? I'm afraid that you vastly overestimate my commitment to ZFS: while I'm somewhat interested in discussing it and happy to provide what insights I can, I really don't personally care whether it succeeds or fails. But I sort of assumed that you might. - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? billtodd at metrocast.net writes: You really ought to read a post before responding to it: the CERN study did encounter bad RAM (and my post mentioned that) - but ZFS usually can't do a damn thing about bad RAM, because errors tend to arise either before ZFS ever gets the data or after it has already returned and checked it (and in both cases, ZFS will think that everything's just fine). According to the memtest86 author, corruption most often occurs at the moment memory cells are written to, by causing bitflips in adjacent cells. So when a disk DMA data to RAM, and corruption occur when the DMA operation writes to the memory cells, and then ZFS verifies the checksum, then it will detect the corruption. Therefore ZFS is perfectly capable (and even likely) to detect memory corruption during simple read operations from a ZFS pool. Of course there are other cases where neither ZFS nor any other checksumming filesystem is capable of detecting anything (e.g. the sequence of events: data is corrupted, checksummed, written to disk). -- Marc Bevand ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
some business do not accept any kind of risk Businesses *always* accept risk: they just try to minimize it within the constraints of being cost-effective. Which is a good thing for ZFS, because it can't eliminate risk either, just help to minimize it cost-effectively. However, the subject here is not business use but 'consumer' use. ... at the moment only ZFS can give this assurance, plus the ability to self correct detected errors. You clearly aren't very familiar with WAFL (which can do the same). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
... And how about FAULTS? hw/firmware/cable/controller/ram/... If you had read either the CERN study or what I already said about it, you would have realized that it included the effects of such faults. ...and ZFS is the only prophylactic available. You don't *need* a prophylactic if you're not having sex: the CERN study found *no* clear instances of faults that would occur in consumer systems and that could be attributed to the kinds of errors that ZFS can catch and more conventional file systems can't. It found faults in the interaction of its add-on RAID controller (not a normal 'consumer' component) with its WD disks, it found single-bit errors that appeared to correlate with ECC RAM errors (i.e., likely occurred in RAM rather than at any point where ZFS would be involved), it found block-sized errors that appeared to correlate with misplaced virtual memory allocation (again, outside ZFS's sphere of influence). ... but I had a box that was randomly corrupting blocks during DMA. The errors showed up when doing a ZFS scrub and I caught the problem in time. Yup - that's exactly the kind of error that ZFS and WAFL do a perhaps uniquely good job of catching. WAFL can't catch all: It's distantly isolated from the CPU end. WAFL will catch everything that ZFS catches, including the kind of DMA error described above: it contains validating information outside the data blocks just as ZFS does. Explain how it can do that, when it is isolated from the application by several layers including the network? Darrell covered one aspect of this (i.e., that ZFS couldn't either if it were being used in a server), but there's another as well: as long as the NFS messages between client RAM and server RAM are checksummed in RAM on both ends, then that extends the checking all the way to client RAM (the same place where local ZFS checks end) save for any problems occurring *in* RAM at one end or the other (and ZFS can't deal with in-RAM problems either: all it can do is protect the data until it gets to RAM). - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
can you guess? wrote: at the moment only ZFS can give this assurance, plus the ability to self correct detected errors. You clearly aren't very familiar with WAFL (which can do the same). ... so far as I can tell it's quite irrelevant to me at home; I can't afford it. Neither can I - but the poster above was (however irrelevantly) talking about ZFS's supposedly unique features for *businesses*, so I answered in that context. (By the way, something has gone West with my email and I'm temporarily unable to send the response I wrote to your message night before last. If you meant to copy it here as well, just do so and I'll respond to it here.) - bill This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 9-Nov-07, at 2:45 AM, can you guess? wrote: Au contraire: I estimate its worth quite accurately from the undetected error rates reported in the CERN Data Integrity paper published last April (first hit if you Google 'cern data integrity'). While I have yet to see any checksum error reported by ZFS on Symmetrix arrays or FC/SAS arrays with some other cheap HW I've seen many of them While one can never properly diagnose anecdotal issues off the cuff in a Web forum, given CERN's experience you should probably check your configuration very thoroughly for things like marginal connections: unless you're dealing with a far larger data set than CERN was, you shouldn't have seen 'many' checksum errors. Well single bit error rates may be rare in normal operation hard drives, but from a systems perspective, data can be corrupted anywhere between disk and CPU. The CERN study found that such errors (if they found any at all, which they couldn't really be sure of) were far less common than I will note from multiple personal experiences these issues _do_ happen with netapp and emc (symm and clariion) -- I will also say that many times you do not read about them because you will find that when they do happen to you one of the first people to show up on your site will be their legal team pushing paper and sharking for signatures. -Wade ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Yager on ZFS
On 14-Nov-07, at 12:43 AM, Jason J. W. Williams wrote: Hi Darren, Ah, your CPU end was referring to the NFS client cpu, not the storage device CPU. That wasn't clear to me. The same limitations would apply to ZFS (or any other filesystem) when running in support of an NFS server. I thought you were trying to describe a qualitative difference between ZFS and WAFL in terms of data checksumming in the on-disk layout. Eh...NetApp can just open WAFL to neuter the argument... ;-) Or I suppose you could just run ZFS on top of an iSCSI or FC mount from the NetApp. The problem it seems to me with criticizing ZFS as not much different than WAFL, is that WAFL is really a networked storage backend, not a server operating system FS. If all you're using ZFS for is backending networked storage, the not much different criticism holds a fair amount of water I think. However, that highlights what's special about ZFS...it isn't limited to just that use case. Its the first server OS FS (to my knowledge) to provide all those features in one place, and that's what makes it revolutionary. Because you can truly use its features in any application with any storage. Its on that basis I think that placing ZFS and WAFL on equal footing is not a strong argument. That was my thinking, and better put than I could, thankyou. --Toby Best Regards, Jason ___ 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
