toasters January 1998

toasters@lists.teaparty.net

35 participants
27 discussions

Start a nNew thread

None
by Kelly Wyatt 16 Jan '98

16 Jan '98

subscribe toasters

1 0

Shortcomings of current NetApps?
by Marc Nicholas 15 Jan '98

15 Jan '98

I'm interested to hear what others think the shortcomings of the current crop of NetApps are. From my experience: * Single logical drive * Weedy SCSI performance * Lack of other RAID implementations * Not quite enough redundancy for truly mission critical applications Don't get me wrong, I love 'em :-) -marc --- Marc Nicholas - Hippocampus OSD, Inc. - Eastern Office 416 979 9000 - fax: 416 979 8223 - http://www.hippocampus.net 125 John St. - Suite #100 - Toronto - Ontario - M5V 2E2 - CANADA "Inter/Intra/Extra[net] consulting, corporate access, hardware and software sales"

14 27

Re: Shortcomings of current NetApps?
by Daniel Quinlan 15 Jan '98

15 Jan '98

rasmus(a)lerdorf.on.ca (Rasmus Lerdorf) writes: > > > 1. Out-of-date SNMP implemention - (no CIFS or disk system statistics, > > for example) > > What do you mean by disk system stats here? The information displayed by the "sysstat" command. You can get the NFS and CPU load via SNMP, but that's it. CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age --- --- --- ---- Only the items with dashes under them are available via SNMP. Dan

1 0

Re: Shortcomings of current NetApps?
by mds46523＠ggr.co.uk 15 Jan '98

15 Jan '98

On Jan 15, 8:46, Brian Tao wrote: > Subject: Re: Shortcomings of current NetApps? > I have a really simple request: a local "rm" command that can > take arguments either on the command line or from stdin. Anyone > running a traditional news spool on a Netapp will probably appreciate > what I'm getting at. ;-) A local "du" command would be rather spiffy too. A special du keyed to UID, ie the space used by a person in a given directory tree would also be kinda cool. I think that there are certain operations where having the filer do the whole thing would save the network, your client machine and the filer itself a lot of time and probably get the job done quicker. The operation could probably be made as low priority as you like and it would still have advantages. Maybe if there were a JAVA VM on the filer that could manipulate the filesystem consistently we could have a bash ourselves. Clearly this could be open to abuse of the Appliance principle, but that's where discipline comes in. > -- > Brian Tao (BT300, taob(a)netcom.ca) > "Though this be madness, yet there is method in't" >-- End of excerpt from Brian Tao -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

2 1

Re: Shortcomings of current NetApps?
by Daniel Quinlan 15 Jan '98

15 Jan '98

Marc Nicholas <marc(a)hippocampus.net> writes: > I'm interested to hear what others think the shortcomings of the > current crop of NetApps are. In addition to what other people have said: 1. Out-of-date SNMP implemention - (no CIFS or disk system statistics, for example) 2. ndmpcopy - incrementals don't work, rsh as UID 0 doesn't work, requires password to be passed on command line 3. NetApps are reboot-prone. Often will reboot when it should have just failed an obviously bad disk. 4. No command line Unix permissions tool for CIFS, the graphical permissions tool uses an undocumented proprietary extension to CIFS (that is, it won't work with Samba). 5. Disk reconstructions take far too long. We had one on a 200GB filesystem take 24 hours (dial set to 2 because any faster was causing severe problems for users, and this is on a decked-out F630). Dan

2 1

Re: Shortcomings of current NetApps?
by mds46523＠ggr.co.uk 15 Jan '98

15 Jan '98

On Jan 15, 11:14, James R Grinter wrote: > Subject: Re: Shortcomings of current NetApps? > On Thu 15 Jan, 1998, Alexei Rodriguez <alexei(a)cimedia.com> wrote: > >I understand the benefits. I just don't care for having 5 4GB > >slices which you have to manage (ala auspex). > > I thought the idea of multiple RAID sets is that you layer one > filesystem atop them all (if you want to. Of course, others want > to have multiple filesystems.) > My thought was that for once we'd have separate fs's in one NetApp box. Which would allow us to have separate snapshot schedules in the same box. Which would be nice and useful. > (Which is something you can, and people do, do with multiple > RAID controllers and Unix systems, etc) > > -- jrg. >-- End of excerpt from James R Grinter -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: Shortcomings of current NetApps?
by mds46523＠ggr.co.uk 15 Jan '98

15 Jan '98

I've got two things to say about these points: (a) Testing. (b) Testing. (insert standard joke about 'it's so important I mention it twice') Seriously though, we've been bitten a once or twice by component failures on our NetApp's but compared to the DOA's we get from Sun, SGI and the rest, I'm quite happy for NetApp to spend more on their factory space, power, personnel and so forth, AND charge a little more. Maybe amortising the RnD costs of NetApp's over the whole range of components isn't as off-putting to users as dumping it all in the base price of the strictly NetApp-designed-and-built hardware and software. Plus it means that NetApp engineers can reasonably expect problems with hardware and software to be NetApp-owned because they were NetApp supplied. NetApp seem to want to make owning their boxes as painless and fruitful as they can. How often do you see Rolls-Royce's in the shop being fitted with parts that aren't approved by RR? Likewise Ferrari? I betcha parts for econoboxes would be cheaper, and might even come from the same basic supplier, but the added scrutiny means added reassurance, which is worth money. Maybe NetApp could introduce a poor-man's NetApp (called something more tactful and market-savvy of course)... But I think that would be more trouble than it's worth no matter which side you're on. On Jan 14, 22:33, Jonah Yokubaitis wrote: > Subject: Re: Shortcomings of current NetApps? > On Wed, 14 Jan 1998, Chris Caputo wrote: > > |>I'm interested to hear what others think the shortcomings of the current > |>crop of NetApps are. From my experience: > | > |My biggest beef is that the upgradability of these things is low. It > |seems that when you buy a unit you are buying a capacity and improvements > |in disk technology don't raise it. For example, our unit uses 4 gig > |drives. Its max capacity is 14 4 gig drives. We'd love to put 9 or 18 > |gig drives in it, but the software doesn't support it. I realize 9 or 18 > |gig drives would raise rebuild time, but that risk should be up to us. > > Amen to that. > > A paste from a sysconfig -r on an F630 > > 1: SEAGATE ST15150W 9107 Size=3.9GB (8388315 blocks) > > The ST15150W is an *OLD* drive that Seagate doesn't even list as a > current product..... > > Some newer drives please? 18gig drives please? It *can't* be that hard > to allow 18gig drives...if it is your programmers didn't do their job > correctly. > > |I also consider the high price per meg to be a shortcoming and because of > |it we are researching and developing alternatives. > > Just negotiate hard with Netapp. I still feel screwed everytime I want > an upgrade from netapp. The above drive model is $355 through > disribution...netapp quoted me $1700/drive. > > Their NVRAM pricing is LUDICRIOUS considering its 3rd party NVRAM > bought from Dallas semiconductor. Ditto for DRAM. > > Netapp: > > Make your money on your wonderful software, and stop trying to price > gouge your customers on *off the shelf* items like Seagate Hard > DRives, Samsung DRAM, and Dallas Semiconductor NVRAM. > > We really aren't that stupid I promise. > > 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 > >-- End of excerpt from Jonah Yokubaitis -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

subscribe
by tonylai 15 Jan '98

15 Jan '98

1 0

Re: Shortcomings of current NetApps?
by Richard Fairthorne 15 Jan '98

15 Jan '98

I would like to see the NetApp re-share CIFS according to cifsconfig.txt after a power-loss, not just a clean shut-down. Richard Fairthorne ---------- > From: Brett Rabe <brett(a)uswest.net> > To: Marc Nicholas <marc(a)hippocampus.net> > Cc: toasters(a)mathworks.com > Subject: Re: Shortcomings of current NetApps? > Date: Wednesday, January 14, 1998 1:18 PM > > > On Wed, 14 Jan 1998 12:40:47 EST, Marc Nicholas wrote: > >I'm interested to hear what others think the shortcomings of the current > >crop of NetApps are. From my experience: > > > > [snip] > >* Not quite enough redundancy for truly mission critical applications > > What other types of redundancy would you like to see? > > Brett > > --- > Brett Rabe Email : brett(a)uswest.net > Systems Administrator - U S West Phone : 612.664.3078 > 600 Stinson Blvd. Pager : 612.613.2549 > Minneapolis, MN USA 55413 Fax : 612.664.4770 > > If you aren't the lead dog, the view is always the same.

2 1

Re: NetApp and amanda
by Alan Judge 14 Jan '98

14 Jan '98

> In article <199801131829.MAA18731(a)vortex.more.net>, > David Drum <david(a)more.net> wrote: >> I was wondering if anyone uses amanda to backup their NetApp(s)? Jan-Pieter> Yup, we do. At least, we used to, until yesterday :) The Jan-Pieter> load on the netapp during phase I of the dump is Jan-Pieter> prohibitively high, and consequently makes our webserver Jan-Pieter> very slow... we're currently rethinking things. We're doing something similar, though in our case we modified amanda itself to understand devices like /@filer1 and understand the output of NetApp dump, rather than replacing dump. Works great, though I have the same concerns as you about the cost of amanda's dump estimates. (Though the cost of creating a snapshot doesn't seem significant for us.) I'd be interested in hearing what solution you come up with. -- Alan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters January 1998