toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

Re: OT: address abuse
by jrg＠acm.org 17 Jan '00

17 Jan '00

On Fri 14 Jan, 2000, Brian Tao <taob(a)risc.org> wrote: >Did the document refer to a product with a name similar to Intel's (I can't really be sure, neither Word'97 or StarOffice will display it correctly...) Sales people, if you actually bother to read anything here, do remember that: 1) We're (mostly) technical people here, and are going to have done our due diligence in picking current and planning future systems 2) We might already have some of your product in our current infrastructure 3) We've probably already looked at your product's marketting materials (You can bet we've all looked at the companies present in NTAP's general sector: http://biz.yahoo.com/research/indgrp/comp_storage_dv.html, any company that pops up in NTAP related news stories, and those listed in their own SEC filings.) 4) We might even have had sales calls and done product evaluations 5) If not, you might one day find yourself sitting across the table from us trying to do a sales call. So do think twice before presuming that we wish to receive a blatant and unrequested sales pitch! James.

1 0

OT: address abuse
by mds＠gbnet.net 14 Jan '00

14 Jan '00

Just a quicky. I was spammed today, personally, by someone representaing a certain TLA (3 letter...) storage company, in the guise of a TLA (2 letter) storage company. It was unsolicited and involved a large enclosed document. I'm just wondering if they got my details from my involvement on the toasters list, and whether anyone else received such an item as well. If so, please holler. -- -Mark ... an Englishman in London ...

5 4

RE: OT: address abuse
by mds＠gbnet.net 14 Jan '00

14 Jan '00

On Thu 13 Jan, 2000, "Robert Black" <bobbl(a)netapp.com> wrote: > > Good question Mark, > > Is it possible for someone/anyone to query the mathworks majordomo > server to get a listing of 'toasters'. I'm not totally familiar > with security relative to majordomo setups! Certainly it's possible in general, though I believe that the toasters list is locked down. At least I think I tried it once in a fit of ennui and curiosity and was politely informed to get lost. 8) I think the addresses may have ben harvested by lurking, or trawling the archive site - so people who've never spoken up probably won't have been sent this. I would also like to think that even this stupidity has its limits and that the party in question didn't email NetApp employees. Though I'm not placing bets, and would be amused if any NetApp worthies were hit too. > bobbl > > PS. I didn't receive said document There is hope! >-- End of excerpt from "Robert Black" -- -Mark ... an Englishman in London ...

3 2

RE: OT: address abuse
by Robert Black 14 Jan '00

14 Jan '00

Good question Mark, Is it possible for someone/anyone to query the mathworks majordomo server to get a listing of 'toasters'. I'm not totally familiar with security relative to majordomo setups! bobbl PS. I didn't receive said document

2 1

address abuse
by s gressel 14 Jan '00

14 Jan '00

There was another bloke from the UK with an email address from (a large three letter storage only company) that asked to be on the list a few days ago. Wonder if there is any connection ;) -----Original Message----- From: mds(a)gbnet.net [mailto:mds@gbnet.net] Sent: Thursday, January 13, 2000 8:05 PM To: toasters(a)mathworks.com Subject: OT: address abuse Just a quicky. I was spammed today, personally, by someone representaing a certain TLA (3 letter...) storage company, in the guise of a TLA (2 letter) storage company. It was unsolicited and involved a large enclosed document. I'm just wondering if they got my details from my involvement on the toasters list, and whether anyone else received such an item as well. If so, please holler. -- -Mark ... an Englishman in London ... --------------------------------- Do You Yahoo!? Talk to your friends online with Yahoo! Messenger.

1 0

Re: OT: address abuse
by mds＠gbnet.net 14 Jan '00

14 Jan '00

On Thu 13 Jan, 2000, Brian Tao <taob(a)risc.org> wrote: > On Fri, 14 Jan 2000, mark wrote: > > > > Just a quicky. I was spammed today, personally, by someone > > representaing a certain TLA (3 letter...) storage company, in the > > guise of a TLA (2 letter) storage company. It was unsolicited and > > involved a large enclosed document. > > Did the document refer to a product with a name similar to Intel's > current low-end consumer CPU? :) I and at least two others have Strangely yes, it did. > received the same spam. At first I thought it was because I'm on the > <certain TLA's> mailing list too, but now it just looks like address > harvesting of this list. What terribly stupid and unethical behaviour on the part of this TLA storage company. Evidently they are in sore need of new trade if they feel the need to resort to low tactics like this. My opinion of them sinks yet further.. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >-- End of excerpt from Brian Tao -- -Mark ... an Englishman in London ...

1 0

Re: NFS UDP xfer size
by mds＠gbnet.net 13 Jan '00

13 Jan '00

On Tue 11 Jan, 2000, "Michael S. Keller" <mkeller(a)mail.wcg.net> wrote: > tkaczma(a)gryf.net wrote: > > > > On Tue, 11 Jan 2000, Michael S. Keller wrote: > > > > > I have one machine tightened to 512-byte > > > transfers because of poor performance at bigger transfer sizes. > > > > I think you really have to look into your network. > > There's not much to check. It goes in one switch port and out another on > the same switch. The interfaces show no errors. I do have the filer > trunked (EtherChannel) and my news clients have hand-tuned MAC addresses > to reduce contention, since the switch does "dumb" switching based on > MAC addresses instead of loads. There's still something rotten in the state of Denmark if you're having to restrict the packet size so very tightly. The increase in interrupt servicing and buffer-handling at either end, relative to even ethernet mtu sized packets is about 3-fold, so seeing *increased* performance as a result is indicative of something seriously wrong somewhere in there. Out of interest, can you say what clients, what switches and what settings you're using in each? Just in case any of us have seen problems with those vendors before it might be worth enumerating exactly what client box, interface, OS and patch levels (within reason, hme/wfe, ip, udp, tcp, rpc, nfs, etc. patches) you're using. Ditto for switch, blades, firmware etc.. You said earlier that you're using Sol2.6, and the trunking suggests you're using qfe's, presumably in UEx000 boxes, but I'm sticking my neck out here. You have piqued my curiosity though! >-- End of excerpt from "Michael S. Keller" -- -Mark ... an Englishman in London ...

4 7

Sun "ge" driver for Solaris 2.8 Early Access?
by beepy＠netapp.com 13 Jan '00

13 Jan '00

Faint hope that someone may have Solaris 2.8 Early Access compatible "ge" driver for the Sun GbE card... Original package does not install? The one I used for 2.7... Sigh.

2 1

Re: NetApp and RDBMS (Oracle/Sybase)
by Richard L. Rhodes 13 Jan '00

13 Jan '00

On 10 Jan 00, at 21:04, Thomas Leavitt wrote: > Dear all... we are researching the purchase of a Network Applicance F740, > for which one of the primary uses would be service of a commercial RDBMS > (either Sybase or Oracle). Until I looked into this last week, I was unaware > this was possible and officially supported... I'm very enthusiastic about > the possibility - so far, feedback on this has been generally positive. I'm > looking for as many people as possible to help validate... > > Thomas > Hi THomas, Last year I purchased 2 F740's for 2 Oracle database servers. While I haven't put them into production yet, I have databases running on them and have done many, many, many imp runs of the db's I need to transfer. Here are my thoughts on this subject: 1) Reliable - so far. They have been rock solid reliable (not that I've had them for real long). 2) Easy to configure. I didn't go to any classes, just read the manual. 2 subjects took some extra work to figure out: qtrees and way snapshot space is allocated. 3) Remotely supportable. I needed disk subsystems that I could put in remote locations and support from a central site. I was greatly disappointed with the remote support capability with every raid system I looked at. The Netapps remote support capabilities, while not perfect is top notch. 4) Fast writes. writes to the nvram is very fast as long as your write rate doesn't overflow the nvram. The nvram is divided into 2 halfs. While one half is accepting writes the other half is being flushed to disk. After the half receiving writes is full, the sides switch. The now full side starts writing to disk and the other side accepts the writes. The problem is if your write load fills up one side before the other side is done being written to disk. At this point you can't get any more write performance out of it. Did I explain this well? It's kind of like Oracle log switches in archive log mode. If Oracle wraps around the logs, but the next log hasn't been archived yet, well, you know, Oracle comes to a halt until the archiving is done. 4) Performance I'm getting? For sequential writes, like when I create an oracle tablespace, I get between 15-20 MB/s. Random writes are around 1.5-2ms from the disk benchmark I used for testing. But I'm not sure of this number. I use AIX systems and the disk benchmark (stkio from stk) works, but IBM does some strange things with NFS that make benchmarking tough - at least it appears that way. From what I can find out, NFS writes aren't supposed to be buffered on the clinet, but it sure looks like AIX is doing something like buffering on the NFS client. I'm still looking into this. The sequential write rates are not as good as some raid systems. I had a HD raid system here that did sequential writes at 35-40MB/s, but it took HD people a full month to get it to the place I could test with it - fast, but completely unsupportable! This is an area where Netapp needs to do more work in order to sell netapps as db disk subsystems. They need to start running/publishing standard disk benchmarks - treating the netapp as a disk subsystem instead as a NFS server. See the next comment below for more . . . . 5) Be carefull in interpreting NetApps benchmarks. THey are NFS benchmarks, NOT disk I/O benchmarks. Check carefull what's in the NFS benchmarks - It's some type of simulated load of a development environment with some percentage mix of reads, writes, catalog access, etc. This in NO WAY describes a db load. I'm not faulting NetApp here, there very clear on their web site on what the benchmarks are and what they represent. I just found it difficult translating NFS ops/s into MB/s or disk i/o's per second. Again, they need to start running/publishing "disk" benchmarks to better sell a netapp as a db disk subsystem. I'd like to see them publish some info like Performance Computing puts in their mag when they test a raid system. 6) There is extra load on your db server due to NFS - this can't be avoided. In general though, other when I'm streaming 20MB/s, the NFS load isn't too bad. At 20MB/s streaming, my RS/6k-F50 (4 processor, 1gb) is running 25-30% in the NFS client (BIOD's). During more normal processing it's barely noticable. 7) The one problem I do have, is that during a high sequential write load, like creating an Oracle tablespace, the high sequential write rate locks out other processes from doing I/o to the netapp. For example, during a create of a 2gb db file, If I (in another window) try and do anything that does I/O, I can wait for 5/10/15 seconds for the command to come back. I'm not sure why this is, but I think this is a problem in AIX, NOT the netapp - because if during the massive sequential writes I try and access the netapp from another computer I get great response. AIX must be queing NFS I/O's or something - which doesn't make sense! 8) I love the way you tune your Oracle db file layout for the netapp - you just don't worry about it. The NetApp automatically sripes things. This makes life real easy. 9) The Netapp makes the normal disk monitoring in unix more difficult. On vmstat/iostat you get wait-for-I/O when the processes are waiting for blocked i/o. At least on AIX, NFS I/O doesn't show up as wait-for-I/O in vmstat or iostat. SOmetimes I see little processor being used and little I/O to the netapp, and I find myself scratching my head wondering what's happening. When I run the same thing on a "normal" disk system I see that it's all wait-for-I/O, in other words, a very heavy random read/write environment. 10) I'm impressed with netapp as a company. They let employees answer to the mailing list - I know of no other company that does this. These people have even admitted to problems and mistakes (this is a strength, not a weakness)! The salesman/techrep I worked with were good. The salesman was a salesman, but not pushy like some I've met. The the tech rep was top notch. They seem to let their product do the selling. I've sat in too many sales meetings (ibm, ems, hds, etc) where they sell you their company and give hype about their products. You know the kind of meeting . . . . you walk out and you really don't know any more about their products than when you went in - lots of words, little real info! I felt that we got straight answers about their products. I think this also seen on their web site. Your can download very detailed info on performance, design, uses, etc. I asked for a copy of their manuals - they gave me a 1 day pass to the paid support area on their web site. I downloaded the manuals and spent a lot of time reading them. 11) I don't like the cost of the netapp. I had prices for raid systems that cost a good bit less than a same sized Netapp. I think this mainly due to che charge for sftw. This is a half knock against netapp. Your paying for a NFS server, but for my use as a db disk subsystem, I don't look at it that way. I needed and purchased a disk subsystem for a database system. For a db disk subsystem, netapp is being compaired against RAID systems, not other NFS servers. 12) Don't broadcast that your running a db on a NFS mounted system unless your willing to take the time and explain everything. It's so AGAINST everything that's taught about db disk subsystem design. 13) A goof I made - AIX supports jumbo packets for gigabit ethernet. I read a old press release from netapp that indicated support for this. It turned out that jumbo packets aren't supported. 14) It still buggs me that you can't edit config files on the netapp through the console. Your have to mount the netapp to a system and edit the files from that system. This makes no sense to me. Even a stupid line editor would be better than nothing! Final thoughts - I like my netapps very much. I wish they cost less. I recomment them very highly for db's. ---------------------------------------------------------------------- Richard L. Rhodes e: rhodesr(a)firstenergycorp.com Ohio Edison Co. p: 330-384-4904 f: 330-384-2514

9 15

Re: netapp mount points, copy times
by Dave Toal 13 Jan '00

13 Jan '00

Folks, These are the results of cp's between vols mounted on two mount points, and on two pairs of mount points. I saw much worse performance from the latter test -- the cp between one pair ran to completion while the other cp (different files, same two vols, different mount points on the same server) hung until the first was done. To take advantage of multiple mount-point nfs ops on a single pair of vols, then, I'd need two interfaces on the client box, one for each pair of mount points? Or is there something I can do on the netapp, equivalent to setting the number of active nfsd? Dave dev3(uhura)root wrote: > Skip, > > I ran some test cp's from sanihome mounted on dev-eval. Same tcp > parameters as production saegis. > > sanihome:/vol/vol0 is mounted on /test/s1 and /vol/nfs_archive is > mounted on /test/s2 > > # time cp /test/s1/dtoal-bigfile /test/s2/dtoal-bigfile > > real 49.9 > user 0.0 > sys 2.7 > # > > Now, if I start two simultaneous cp's, one from s1 to s2 and the > other from s2 to s1, performance goes way down. I ran these in two > separate windows: > > # time cp /test/s1/dtoal-bigfile /test/s2/dtoal-tmp > > real 1:37.8 > user 0.0 > sys 2.8 > # > > # time cp /test/s2/dtoal-bigfile /test/s1/dtoal-tmp > > real 1:39.5 > user 0.0 > sys 4.8 > # > > With both cp' > processes running simultaneously, against the same mount point, time to > complete is about 2x a single cp. > > This also happens if you do a copy to the *same* mount point: > > # time cp /test/s1/dtoal-bigfile /test/s1/dtoal-bigfile2 > > real 1:34.1 > user 0.0 > sys 2.0 > # > > Which means i/o against that mount point is happening serially. > > I thought that if I set up four separate mounts and copied one > file between each *pair* I'd get performance similar to the first case. > Turns out not. These two copies were started at the same time: > > # time cp /test/s1/dtoal-bigfile /test/s2/dtoal-third-big-file > > real 1:14.6 > user 0.0 > sys 2.7 > # > > # time cp /test2/s2/dtoal-tmp /test2/s1/dtoal-fourth-big-file > > real 2:26.1 > user 0.0 > sys 2.3 > # > > /test/s1 and /test2/s1 are both /vol/vol0; /test/s2 and /test2/s2 > are both /vol/nfs_archive. I had `while sleep 1 do ls -l` running in a > separate window, and I watched the second copy essentially hang until the > first was done -- after the first was done, the second took off. > > This is not the behaviour I expected to see from the netapp. > > Dave

1 0

Jump to page:

2025

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