toasters October 1998

toasters@lists.teaparty.net

60 participants
75 discussions

RE: (small?) feature request
by Weeks, Thomas 21 Oct '98

21 Oct '98

> -----Original Message----- > From: marc_merlin(a)magic.metawire.com > [SMTP:marc_merlin@magic.metawire.com] > Sent: Tuesday, October 20, 1998 7:07 PM > To: toasters(a)magic.metawire.com > Subject: Re: (small?) feature request > > On 19 Oct 1998 06:51:22 -0700, Teemu Peltonen <teepee(a)netti.fi> wrote: > >Yet better, why wouldn't NetApp build and distribute the SSH > implementation > >outside the USA? Then it would be available to all users, no matter > where > >they lived. One of the most popular SSH implementations comes from > >Datafellows, a Finnish company. > > That wouldn't work, unless they move their whole engineering > building > outside of the US (I don't think Canada would do, because they have > similar > laws, and treaties with the US). > If they were to hire some programmers let's say in Australia, they > wouldn't > be allowed to merge the code with their source tree, and ship it > from the > US. The shipping builds would have to be compiled and sold from > Australia. > But even that wouldn't quite work because it means that the US > programmers > would have to leave hooks in their code for the encryption > module, and > exporting a program with hooks for an encryption engine also violates > ITAR > :-( > [Weeks, Thomas] Haha... The US wants to play this stupid little game, then Play it THEIR way! NetApp ought to take the same approach as all the floating casinos! Build a "NetApp Assembly Boat" just off the coast where the US office can send their hardware and the Aussys/Finnish can send their cypto/ssh code! I swear.. This is supposed to becoming a "Global Community"... Why doesn't someone pull the funding plug for the NSA/CIA?... Anyway... that's another monster all together. > That's why I was saying that they'd more or less have to move their > whole > engineering team outside of the US (and might even have to hire > non US > programmers because I'm not so sure that a US citizen is allowed to > develop > encryption software for another country). > [Weeks, Thomas] How about the "Good Ship NetApp"!! haha.. Really though guys... That might actually be something to LOOK at! > No, things are far from easy :-( > > Marc > [Weeks, Thomas] Thomas Weeks GTE SYSTEMS ENGINEER Testing-Integration Center "The Pit" Brooks AFB, DSN 240-5444

2 1

Re: (small?) feature request
by mds＠ns.gbnet.net 19 Oct '98

19 Oct '98

Try slipping native ssh support on a filer past export controls - we'd be very unhappy in the UK to find our company prevented from trading for breaking the arms embargo along with our suppliers. Now, allowing us to do something well defined, perhaps with the Java VM, for *ourselves* along the lines of adding a secure control protocol to our filers...now *that* would be a fine thing.

4 3

Postmark
by Marc Nicholas 17 Oct '98

17 Oct '98

Out of interest, anyone run Postmark benchtests on F700 series filers as per the whitepaper on the NetApp website? I'd be interested to see the results and don't have access to any of the 700 series... -marc -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" vox://416.979.9000 fax://416.979.8223 http://www.hippocampus.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Host your business website for only $29/month! 1.877.GO.HIPPO

1 0

RE: Logging CIFS logins
by Allison, Bridget 16 Oct '98

16 Oct '98

I'm late into this thread so my apologies if someone has already given this info. The release of DataONTAP targeted for 1st quarter CY99 will include access logging for CIFS. You'll be able to track file and directory access and user logon/off for CIFS users. This is a subset of the auditing available for NT servers. More details will be available as the release gets closer. ===================================== Bridget Allison Manager, NetApp Windows Networking Network Appliance Inc. office: (408) 367 3419 cell: (408) 823 1126

1 0

Re: fcal and the 760
by Daniel Quinlan 15 Oct '98

15 Oct '98

Scott Schoenthal <sas(a)netapp.com> writes: > Support for the SNTP subset of NTP is currently scheduled to ship in > the next major release of ONTAP which is targeted for Feb/Mar '99. That's good news. Will it work against the standard xntpd server as well as against SNTP servers? - Dan

2 1

Backing up data
by Jason Middlebrooks 15 Oct '98

15 Oct '98

Since the 700 series filers only allow one SCSI backup device to be attached to a Filer how is it possible to back up 1TB of data in timely manner. I am talking about backing up in a 8 to 12 hour time frame. Any ideas would be great. Thanks, Jason Jason Middlebrooks Systems Engineer Direct Connect Systems Phone: 770-933-9327x270 2264 Northwest Parkway, Suite I Pager: 888-502-1625 Marietta, GA 30067 Fax: 770-933-9272

3 2

None
by jason 15 Oct '98

15 Oct '98

toasters unsubscribe

1 0

Re: fcal and the 760
by Keith Brown 15 Oct '98

15 Oct '98

>| As far as performance goes, the three FCAL loops are peers in the system. > >Is this true in a clustered failover environment as well Sure. >or can I tag >the failover loops as having a lower priority than the "local" loops? What exactly do you mean by "local loops"? If by "local loops" you mean FCAL loops that are private to an individual filer within the cluster, then I'm not entirely sure that we support that type of configuration anyway. In a cluster configuration, each filer requires at least two FCAL adapters, one to connect it to its primary disk array, and another to connect it to its secondary disk array which it takes over in the event of a failure (which is the primary of the other filer in the cluster) . It is "normal" for that to be the beginning and end of the story, except in the case of a large capacity cluster that requires two pairs of FCAL adapters per filer (see below). Just from the quantity perspective, the only filers that can or will be able to receive a third FCAL loop are the F630 and F760 units, so this discussion is somewhat moot in the context of an F740. As a point of information though, the Data ONTAP 5.2 release only supports F630 filer clustering. It does include support for the "large capacity" cluster I mentioned above (4 FCAL adapters per system, but topping out at 168 drives across the 4 loops, not 224, so an "obvious" sample configuration would involve implementing 42 drives per loop, giving each *individual* system a capacity of 84 drives or ~722 GB gross, adding up to the ~144 GB gross in the whole cluster), but F700 series clustering for the F740 and F760 systems is not yet shipping. Patience... :-) >| Well yes, but distance-from-the-controller is not a significant influencer >| of device performance on an FCAL loop. This type of fibre channel > >There must be some guidelines though. I would think that you would not >want to keep all the loops within some reasonable distance. I don't think so. That's kinda like worrying about communications between the nodes at the opposite ends of an Ethernet segment being slower because the bits have further to walk! :-) >That is, I >would probably want to put my filer in the middle of the rack so all >loops are semi-equal as opposed to at the end of the rack (thinking that >a filer that takes up 3 racks with 3 fully populated loops). Yes, there may be some physical "can it reach" issues on a three FCAL loop system. At the moment, I know that our standard issue FCAL cable that takes an FCAL adapter output plug on a filer to the input of the first shelf is just one meter long. That's no problem on a two loop system, as you can just go taking off in opposite directions to go along the shelf chain for each loop (one chain heads off up the rack, the other down, that kind of thing...) but I guess it does get kinda interesting when you've got three loops to worry about. I'll have to leave this one to someone at NetApp who knows exactly how we recommend this work physically. >Indeed. fcal is quite spiffy. It is a thing of beauty. :-) >Actually, why the decision to use copper instead of fiber? I think the reasons were plentyfold. Affordabality was certainly in the mix. Keith

4 5

Macintosh Access
by Graham C. Knight 15 Oct '98

15 Oct '98

Help! Does anyone know of a piece of software that will run on Unix or NT that will allow a NAC file system to be used by a Macintosh? Or any tricks that will allow NT to re-export a CIFS share via appletalk? I've had it with CAP - after finding yet another bug. Our usage of Filers depends on being able to access the filers from macintosh (with no client software on the mac!). If anyone has any suggestions i'd really like to hear them. Thanks, Graham

7 8

Re: file system size limit
by mds＠ns.gbnet.net 15 Oct '98

15 Oct '98

> I know that the argument will be that I should break up the single filesystem into > multiple volumes, since then I can fine tune the options (snapshots, snap schedules, > etc) per volume. That is all good, but when you start getting 100's of GB of data, > sometimes it does not split cleanly (and updating the vfstab N clients becomes a chore, > no matter how automated you have it (well, save for NIS, but who does that?)). We do. It works. We're happy.

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 October 1998