toasters June 1999

toasters@lists.teaparty.net

85 participants
118 discussions

Re: Converting F230 SCSI drives to F740
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/15/99 11:18:54 you wrote: >If there is a problem with the boot image on disk, Intel when you really need >Alpha would be considered a problem, you can boot from floppy and run the >`download' command to refresh the boot image. Right. Although for the move, it doesn't sound like he'll need to do this; if he can set the alpha to use vol1 and make it the root volume and move the other disks over as vol0 (can you do that without the filer wanting to rename things?) then he can just type "download" on the running filer after the move and refresh the vol0 disks with the alpha image. Bruce

1 0

Re: the virus
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 10:45:48 you wrote: > >In theory, The worm/trojan he wrote could have deleted the research for >the drug that would one day save his life... Unfortunately Netapp probably sold them a filer so snapshots allowed them to recover the data. :) Bruce

1 0

Re: the virus
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 14:26:05 you wrote: >On Mon, 14 Jun 1999, Douglas Ritschel wrote: > >> I think it should be a capital offense. > >But not to the virus writers, but the people that ignorantly open them. I >think that Microsoft at al. should be held accountable for the ease with >which the worm takes advantage of those systems. I can't resist this opportunity to take a jab at Microsoft by noting that I think the people who ignorantly use Microsoft mail clients that allow them to be taken advantage of are partly accountable too. :) Bruce PS - No, I'm not really defending the virus writers. And oddly enough I didn't get hit, despite being on several lists.

1 0

Re: AFS/DFS??!! :-) (and FTP!)
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 14:35:34 you wrote: > >> Are the binaries modular, i.e. only licensed modules are installed into >> memory? > >No - ONTAP is a single image with all modules linked into it. > > Right... my point was that it's still a very small code image compared to the 128MB+ your filer is going to have, even if the image is (allegedly) ten times larger than it used to be. I suppose certain features like CIFS will use more memory to allocate certain data structures for buffers and the like, but I was under the impression that if you weren't using it, this memory wasn't going to be allocated. (Ditto anything extra a particular network card like ATM may need to allocate to operate.) Bruce

1 0

Converting F230 SCSI drives to F740
by Mike Ball 15 Jun '99

15 Jun '99

We have a F230 with about 100GB of data. We have just purchased a F740 with a shelf of 18GB Fibre drives and two empty dual SCSI shelves. We have 9GB SCSI drives on the F230 which can be moved to the F740 Dual SCSI shelves. My question is since we are running a Data Ontap 4.3.3 on the F230, I will be upgrading it to 5.2.2 before I physically move the SCSI drives over to the F740 system. Since the source code for the Data Ontap on the F230 is Intel based versus Alpha based on the F740 am I going to run into issues. As it stands right now, I am planning on having my root volume to boot off of on the Fibre drives. Since the volume on the F230 is already named vol0 I am renaming the root volume on the F740 Fibre drives to vol1. Once this has been completed, it looks like I can simply power down both the F230 and the F740, move the disks from the F230 SCSI shelves to the F740 SCSI shelves. Power up the Fibre and SCSI shelves on the F740, and be on my way. The F740 will boot off the root volume on the Fibre drives and I should be able to see both volumes once the system has completed the boot process. Once both volumes are confirmed to be online and functioning , I would then make vol0 (volume on SCSI disks) the root volume and reboot the system. Does everything here sound correct and if so how will the Intel Data Ontap code on the SCSI drives from the F230 be converted to Alpha code?

2 1

Thanks.
by Shaun T. Erickson 15 Jun '99

15 Jun '99

I recently mentioned that we were having major trouble with our F540. I just wanted to thank the NetApp folks who've been so helpful the past week: Puneet Anand, Jim Ripley, Kirk & Pamela. They really came through for us. Our system isn't fixed, but our replacement loaner system is up and running and serving our data just fine. Thanks, NetApp. :-) -ste Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (201) 310-9941

1 0

NFS ACLs
by tkaczma＠gryf.net 14 Jun '99

14 Jun '99

Just came across this in Solaris docs: --- NFS Parameters for the nfs Module [...] nfs_acl_cache - This symbol controls whether ACLs are cached on clients that are using the NFS_ACL protocol. --- Does anyone know of any info on the NFS ACL protocol? Is this what we were just speaking of? Tom

2 4

Re: AFS/DFS??!! :-) (and FTP!)
by sirbruce＠ix.netcom.com 14 Jun '99

14 Jun '99

On 06/12/99 17:04:02 you wrote: > >>DFS is a pretty small market. AFS isn't much better, assuming you >>mean Andrew. If you're talking Apple, now there's a potential market. >Apple toooooo. >In fact we have over 400 of those puppies in our dept alone and when we >bough the very first FAServer450 (No, not the F540, the 450 with 2 G disks!) Actually, before the 450 was the 400, which could only hold half as many disks (7). If you wanted 14 you had to buy a second cabinet and run an external SCSI cable to it. I thought the cabinets looked pretty cool, but the 450 was certainly impressive. I've never seen a bigger PC tower case in my life! Also, for a while 1G disks were supported as well. (Actually, I suspect they still are, if you had one lying around that you could fit!) But by the time Netcom got its first filer in late 1993 2G disks were the norm. >in early '94 that was the very first request I had with their then V.P. >On the other hand I have mixed feeling when requesting new features >and additional protocol support. One of the key strength of an appliance, >in my school, is it's simplicity of usage and administration. >When the first FAServer's rolled out it had fewer than 50 commands with >a 300 page admin book and hell of a fewer lines of code compared to other >traditional UNIX systems. However, the admin book, while thin, was seriously lacking in a lot of important details! The appliance is still really simple *except* in the edge cases, and then you have to know exactly what you're doing. This is the trade-off you get for faster response when there's a failure -- you can fix the problem yourself. >As we request all these neat features I wonder how much are we shooting >ourselves on the foot. I think so long as the filer sticks to *file service* and the related protocols it will be fine. For the most part having the other features "around" doesn't hurt performance for the other functions. In other words, having the trunking code or the PC-NFS support doesn't hurt your NFS access performance when you aren't using them (or even when you are). If the filer got into other areas... for example, trying to be a DNS server and a SMTP server on the same box, then I'd be annoyed. (I must reluctantly accept the idea that the filer should be a Domain Controller for NT, simply because that's a necessary component for their file service.) >Once I heard that just adding ATM support on the NIC increased the number >of lines of code by an order of magnitude! I doubt ATM alone was that bad. 10 times, no. 2 times, maybe. :) I don't know exactly how small the 1.0 version code was; I suppose it could have taken up as little as 10% of the original floppy. So today's code might be 10 times bigger now, but I don't think that's all due to ATM. I suspect CIFS support must be a big chunk. But you're still talking a very small part of the filer's overall memory reserve, so bigger executables aren't really a factor in performance. Most of code size concerns are a maintenance issue. It is all supposedly highly segmented and integrated, however, so all those extra lines of code don't slow down the data path from the network interface down to WAFL appreciably compared to the original code. There is more work to be done in a multiprotocol environment, but it is well worth the tradeoff. Bruce

3 2

RE: the virus
by Garrett Burke 14 Jun '99

14 Jun '99

Hi, Files on the toaster will be set to size zero. Be very careful if your toaster contains source code as the virus attacks .cpp, .c and .h files. Thank god for snapshots. GB > ---------- > From: Steve Armijo[SMTP:armijo@cs.unm.edu] > Sent: 11 June 1999 09:17 > To: toasters(a)mathworks.com > Subject: the virus > > > ok, so amid all this wild virus scare, does anyone here know what the > potential of this is to affect PC users who have shortcuts/mapped drives > pointing at toasters? > > -steve > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

9 11

RE: NFS ACLs
by tkaczma＠gryf.net 14 Jun '99

14 Jun '99

Warning, he worm finaly made it to the newsgroup. Tom On Mon, 14 Jun 1999, Kinney, Roger wrote: > Hi ! > I received your email and I shall send you a reply ASAP. > Till then, take a look at the attached zipped docs. > bye. > <<zipped_files.exe>> >

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

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 June 1999