Al Hopper wrote: > On Tue, 27 Jun 2006, Gregory Shaw wrote: > > >>Yes, but the idea of using software raid on a large server doesn't >>make sense in modern systems. If you've got a large database server >>that runs a large oracle instance, using CPU cycles for RAID is >>counter productive. Add to that the need to manage the hardware >>directly (drive microcode, drive brownouts/restarts, etc.) and the >>idea of using JBOD in modern systems starts to lose value in a big way. >> >>You will detect any corruption when doing a scrub. It's not end-to- >>end, but it's no worse than today with VxVM. > > > The initial impression I got, after reading the original post, is that its > author[1] does not grok something fundamental about ZFS and/or how it > works! Or does not understand that there are many CPU cycles in a modern > Unix box that are never taken advantage of.
Just because there are idle cpu cycles does not mean it is ok for the Operating System to use them. If there is a valid reason for the OS to consume those cycles then that is fine. But every cycle that the OS consumes is one less cycle that is available for the customer apps (be it Oracle or whatever, and I spend a lot of my time trying to squeeze those cycles out of the high end systems). The job of the operating system is get the hell out of the way as quickly as possible so the user aps. can do there work. That can mean offloading some of the work onto smart arrays. As someone once said to me once, a customer does not buy hardware to run an OS on, they buy it to accomplish some given piece of work. > > It's clear to me that ZFS provides considerable, never before available, > features and facilities, and that any impact that ZFS may have on CPU or > memory utilization will become meaningless over time, as the # of CPU > cores increase - along with their performance. And that average system > memory size will continue to increase over time. This is true and will probably be true for ever and has been going on ever since the first chip. There has always been more demand for more power by the end users. However just because we have available cycles does not mean the OS should consume them. > > Perhaps the author is taking a narrow view that ZFS will *replace* > existing systems. I don't think that this will be the general case. > Especially in a large organization where politics and turf wars will > dominate any "technical" discussions and implementation decisions will be > made by senior management who are 100% buzzword compliant (and have > questionable technical/engineering skills). Rather it will provide the > system designer with a hugely powerful *new* tool to apply in system > design. And will challenge the designer to use it creatively and > effectively. It all depends on your needs. The idea of ZFS of providing raid capabilities is very appealing for those systems that are desk top units or small servers. But where we are talking petabyte+ storage with 30+ gig/sec of IO bandwidth capacity, I believe we will find the CPUs are going to consume way to much to handle the IO rate in such in environment, at which time the work needs to be off loaded to smart arrays (I have to do that experimentation yet). You do not buy a 18 wheel tractor trailer to simply move a lawnmower from job site to job site, you buy a SUV, pickup truck or trailer. Vice versa you do not buy a pickup truck to move a tracked excavator, you have a tractor trailer. > There is no such thing as the universal screw-driver. Every toolbox has > tens of screwdrivers and tool designers will continue to dream about > replacing them all with _one_ tool. > How true. ZFS is one of many tools available. However the impression I have been picking up out of here at various times is that alot of people view ZFS as the only tool in the tool box, thus everything is looking like a nail because all you have is a hammer. If ZFS is providing better data integrity then the current storage arrays, that sounds like to me an opportunity for the next generation of intelligent arrays to become better. Dave Valin > [1] Sorry G regory. > > Regards, > > Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] > Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT > OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 > OpenSolaris Governing Board (OGB) Member - Feb 2006 > _______________________________________________ > 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
