On January 24, 2010 Frank Cusack wrote: >That's the point I was arguing against. Yes, that's correct.
>You did not respond to my argument, and you don't have to now, Thanks for the permission. I'll need that someday. >but as long as you keep stating this without correcting me I will keep >responding. As is your perfect right. You have my permission to say anything you like; I do like a guy who's persistent. But if you'll re-read what I wrote, I think you may have left out my implicit phrase "... for me..." in describing my problem and my solution. I would never presume to correct you. Your situation is almost certainly different from mine. I do however believe that situations like the one we are describing must be described in context, because when we start discussing failure rates and economics as well as different objectives, the scoring polynomials get complicated fast. >The size of the drive has nothing to do with letting you put another drive on, >for >more redundancy. That is correct. I can obviously buy more drives no matter how big they are. As I used to tell girls in bars, I'm not really this tall, I'm just sitting on my wallet. It was remarkably effective. 8-) "Just buy more, bigger drives" is a good solution, if the sheer number of bits or lowest cost per bit is what you're after. However, I may not have been clear about my point. More, smaller drives, within limits may be better in some circumstances, depending on how you look at the problem. I thought that I was clear about the "within limits/practicality/reason" approach, in my rambling. If not, let me say it. No generality is worth a d..., including this one. There is only fitness for context. Do what's practical within your context. And have a good time at it. But contexts are rarely as simple as "get more bits" or "get the densest drives" when you have multiple objectives. As I obviously muffed explaining, more and smaller drives, for not too much cost penalty (where we all get to define how much smaller and how much more cost penalty in our own personal contexts) leads to a lower recover/resilver time per failed disk than grabbing the densest, most bit stuffed drives; this is because to a first order, the time to get bits onto a new disk is proportional to the number of bits. This changes in steps as the interfaces get faster, but is likely to not keep up with the sheer number of bits. I know this because I read it on the internet and that makes it true, right? 8-) I've got that reference here somewhere if it's pertinent. Obviously, taken to extreme, a zillion one-bit drives is not a cost effective solution. We're all here at least partly because a single zettabyte drive has some issues as well. I suspect that on this continuum, there is not a single answer of X drives of Y size is the best answer for all situations. Maybe there are two answers, perhaps even three. In my own, personal, dim-witted, benighted context of evaluation, for which I reserve the right to be wrong, I judged that for me, at this time, in the technological context I happen to be in right now, it's better to get a few more drives to get more increments of physical failure possibility if that also includes more redundancy mechanisms (i.e. raidz3) so that I have a better chance of correcting silent bit errors before a second drive failure makes the data lost. In that limited, miniscule, probably useless context where the I/O rates onto and off the disk are the same for all the drives being considered, I judge that cutting the time to re-silver a replacement disk may be more desirable than getting the absolute most disks. It's a different viewpoint, albeit probably limited and shortsighted as I've stated. But I thought it might be helpful to someone else, if only as a starter idea for thinking about disk drives on a basis other than bits/dollar. Perhaps the most bits p er dollar is, in fact, the best strategy; however, it ought to be checked out if there are other ways to looking at it, depending on what you're trying to do. > smaller drives require LESS redundancy for the same level of availability Maybe that's the problem. I'm not after availability. Back in the bad old days when I sold my soul to a giant corporation every day, we distinguished between reliability, availability, and serviceability. I'm after serviceability. Reliability and availability are close, but not the same concepts. Anyway, thanks for hanging in there and helping me figure it out. I guess I just had this simple minded idea that all situations of evaluating how many drives of what density might not reduce to only the lowest cost per bit at any given time. Silly, right? 8-) R.G. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
