On Thu, 12 Jun 1997, Dave Hitz wrote:
Although marketing certainly has input, the space restrictions also come from engineering droids. During normal operation the smaller machines could certainly handle more disk, but the time required for something like RAID reconstruction could get dangerously long.
Is this the reason why the F210 can still only use around 50GB of
disk, even though it can physically accomodate more using 9GB drives?
In order for a RAID reconstruction to complete, you have to read all of the data on all of the other disks. So RAID reconstruction time is proportional the the amount of data, not proportional to the number of disks.
Dave Hitz hitz@netapp.com Network Appliance (408) 367-3106
On Thu, 12 Jun 1997, Dave Hitz wrote:
In order for a RAID reconstruction to complete, you have to read all of the data on all of the other disks. So RAID reconstruction time is proportional the the amount of data, not proportional to the number of disks.
Hrm... how about dropping in a P200 in the motherboard CPU socket? ;-)
On Thu, 12 Jun 1997, Brian Tao wrote:
|On Thu, 12 Jun 1997, Dave Hitz wrote: |> |> In order for a RAID reconstruction to complete, you have to read all |> of the data on all of the other disks. So RAID reconstruction time |> is proportional the the amount of data, not proportional to the |> number of disks. | | Hrm... how about dropping in a P200 in the motherboard CPU socket? |;-)
Amen. What are the technical limitations of doing this on a FA220/330? Please no marketing reasons, as I remember what Netapp wanted to charge for 70ns NVRAM simms....$1000/each. We bought direct from dallas semiconductor the _exact_ part # that netapp uses for nvram. $84/each. What would be the limitations on dropping a P166 or P200 cpu into a 220/330 box?
Jonah
Jonah Barron Yokubaitis | Austin|San Antonio|Houston President | Dallas|Fort Worth|Boerne Texas.Net | Georgetown|Dripping Springs http://www.texas.net | Making 56k affordable
Seems like the real question is would customers be willing to trade rebuild time for additional capacity on the low end. I'd certainly like to see the option available because we would favor high capacity whereas other customers may favor low rebuild times.
Chris
On Thu, 12 Jun 1997, Dave Hitz wrote:
On Thu, 12 Jun 1997, Dave Hitz wrote:
Although marketing certainly has input, the space restrictions also come from engineering droids. During normal operation the smaller machines could certainly handle more disk, but the time required for something like RAID reconstruction could get dangerously long.
Is this the reason why the F210 can still only use around 50GB of
disk, even though it can physically accomodate more using 9GB drives?
In order for a RAID reconstruction to complete, you have to read all of the data on all of the other disks. So RAID reconstruction time is proportional the the amount of data, not proportional to the number of disks.
Dave Hitz hitz@netapp.com Network Appliance (408) 367-3106
Seems like the real question is would customers be willing to trade rebuild time for additional capacity on the low end. I'd certainly like to see the option available because we would favor high capacity whereas other customers may favor low rebuild times.
This is a tough question. There's an old UNIX saying:
We sell rope. If you hang yourself, it's your own fault.
I think that part of what distinguishes appliance vendors is that we don't like to sell rope. For instance, we've got no way to disable RAID in our system, and we always include NV-RAM.
On the other hand, as our customers become more sophisticated and familiar with our products, perhaps it does make sense to be more flexible.
Dave Hitz hitz@netapp.com Network Appliance (408) 367-3106
This is a tough question. There's an old UNIX saying:
We sell rope. If you hang yourself, it's your own fault.
I think that part of what distinguishes appliance vendors is that we don't like to sell rope. For instance, we've got no way to disable RAID in our system, and we always include NV-RAM.
On the other hand, as our customers become more and sophisticated familiar with our products, perhaps it does make sense to be more flexible.
I doubt that customers will ever become sophisticated. As long as coporate penny pinchers sign the purchase orders, they'll take the low road and expect us to miraculously save the day when something goes south. I think think it's a plus that NetApp sets margins of acceptible performance and sticks to them.
++-------------------------------------------------------------------- Christoph Doerbeck Motorola ISG doerbeck@dma.isg.mot.com
On Thu, 12 Jun 1997, Dave Hitz from netapp wrote:
This is a tough question. There's an old UNIX saying:
We sell rope. If you hang yourself, it's your own fault.
<grin> This reminds me of the many years we have had toasters, been on your beta program (not because we needed it) and have been hanged by y'all.
On the other hand, as our customers become more sophisticated and familiar with our products, perhaps it does make sense to be more flexible.
hear, here.
Flexibility is an excellent attribute when dealing with good customers, for one thing it breeds loyalty. I'd prefer to hang myself by choice than be put on a choke collar. A choke collar is a sure way to breed resentment.
-Caroline, yanked and not enjoying it
before commenting on this mail, i'd like to thank everyone for the spirited discussion on this issue. i'm particularly grateful to Cheena Srinivasan for his even-handed comments of Jun 5th. i don't see how disussing this openly can hurt NetApp or us toaster owners, and i'm pleased that NetApp agrees.
On Thu, 12 Jun 1997, Dave Hitz wrote:
Seems like the real question is would customers be willing to trade rebuild time for additional capacity on the low end. I'd certainly like to see the option available because we would favor high capacity whereas other customers may favor low rebuild times.
This is a tough question. There's an old UNIX saying:
We sell rope. If you hang yourself, it's your own fault.
hah! as a man with years of rope burns, i couldn't agree more.
I think that part of what distinguishes appliance vendors is that we don't like to sell rope. For instance, we've got no way to disable RAID in our system, and we always include NV-RAM.
i note that you do already give us rope, in the form of raid.reconstruct_speed, to hang ourselves a little, and we are trusted not to twist that around our necks. the question is not whether to sell rope, but how much rope is too much.
On the other hand, as our customers become more sophisticated and familiar with our products, perhaps it does make sense to be more flexible.
agreed, particularly with respect to allowing the customer to decide if he's got CPU to spare. for me, NetApp is most useful in working with me to discover the best use i can make of my toasters in my setup without unduly exposing myself, rather than laying down a blanket law designed to protect banks, software development shops, and office supplies vendors equally.
on the other other hand, i also quote, and approve of the latter half of, Christoph Doerbeck's statement:
I doubt that customers will ever become sophisticated. As long as coporate penny pinchers sign the purchase orders, they'll take the low road and expect us to miraculously save the day when something goes south. I think think it's a plus that NetApp sets margins of acceptible performance and sticks to them.
i think that it's wonderful that the out-of-the-box toaster comes armoured against all reasonable crises. i also note the old adage that "the only secure computer is a dead one", and feel that there's a fine line between *helping* the customer to run safely, and *forcing* the customer to run so safely that he can't do anything useful.
on a final, unrelated note, absent any objections, we're looking at getting a web-indexed archive of the toaster list postings together. news on that as it's made.
Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C "Microsoft (tm) is a single-sofa supplier"
On Fri, 13 Jun 1997, Tom Yates wrote:
before commenting on this mail, i'd like to thank everyone for the spirited discussion on this issue. i'm particularly grateful to Cheena Srinivasan for his even-handed comments of Jun 5th. i don't see how disussing this openly can hurt NetApp or us toaster owners, and i'm pleased that NetApp agrees.
Amen. I think it is important to have a forum where our views as customers can be expressed to employees of NetApp in a way that bypasses the normal sales-droid filter. Any perceived negativity from me is only because I feel comfortable voicing the issues our company has with NetApp products, in hopes of improvement.
Chris
+----- On Thu, 12 Jun 1997 22:23:01 PDT, writes: | > Seems like the real question is would customers be willing to trade | > rebuild time for additional capacity on the low end. I'd certainly like | > to see the option available because we would favor high capacity whereas | > other customers may favor low rebuild times. | | This is a tough question. There's an old UNIX saying: | | We sell rope. If you hang yourself, it's your own fault. | | I think that part of what distinguishes appliance vendors is that we | don't like to sell rope. For instance, we've got no way to disable | RAID in our system, and we always include NV-RAM. | | On the other hand, as our customers become more sophisticated and | familiar with our products, perhaps it does make sense to be more | flexible.
I was cleaning up my toasters folder when I saw this and one of the interesting things with raid groups as I see it is that we can divide the system up in groups that can be rebuilt in a reasonable time without restricting the total size of the filer.
Any comments?
/Michael
On Thu, 12 Jun 1997, Dave Hitz wrote:
In order for a RAID reconstruction to complete, you have to read all of the data on all of the other disks. So RAID reconstruction time is proportional the the amount of data, not proportional to the number of disks.
I noticed that even on an F220 with raid.reconstruct_speed set to 10, sysstat reports the CPU is only about 60% busy. Was this a conscious design decision, to reserve some CPU for its normal NFS duties? The disk write speed is barely 1MB/sec, so it shouldn't be a physical drive limitation. Is the SCSI bus saturated, perhaps?
In some cases it may be beneficial to have the NetApp just go all-out on rebuilding on a spare drive and forget about doing any NFS until it leaves degraded mode. I suppose this is another "hang-onself- with-enough-rope" issue. ;-)
f220> sysconfig -r RAID Disk DISK_ID# HA.SCSI# Used (MB/blks) Phys (MB/blks) --------- -------- -------- -------------- -------------- parity 0 0.0 4000/8192000 4095/8386728 data 1 1 0.1 4000/8192000 4095/8386728 data 2 2 0.2 4000/8192000 4095/8386728 data 3 3 0.3 4000/8192000 4095/8386728 data 4 10 0.5 4000/8192000 4095/8388312 data 5 9 0.4 4000/8192000 4095/8388312 data 6 8 0.6 4000/8192000 4095/8388312 data 7 7 9a.1 4000/8192000 4095/8388312 (reconstructing, 1% done) data 8 6 9a.2 4000/8192000 4095/8388312 data 9 4 9a.0 4000/8192000 4095/8388312 f220> sysstat 1 CPU NFS CIFS HTTP Net kb/s Disk kb/s Tape kb/s Cache in out read write read write age 53% 0 0 0 0 0 9216 992 0 0 >60 54% 0 0 0 0 0 8928 992 0 0 >60 59% 0 0 0 0 0 8928 1024 0 0 >60 58% 0 0 0 0 0 8928 960 0 0 >60 60% 0 0 0 0 0 8928 992 0 0 >60 61% 0 0 0 0 0 8928 1024 0 0 >60 61% 0 0 0 0 0 8208 1024 0 0 >60 55% 0 0 0 0 0 8928 992 0 0 >60 62% 0 0 0 0 0 9216 992 0 0 >60