toasters

toasters@lists.teaparty.net

13515 discussions

Re: command reference guide discontinued in 5.x
by applix!jimsparc!jim＠uunet.uu.net 19 May '98

19 May '98

>command reference guide has been discontinued in 5.x? you're kidding, right? You have to be kidding! -- Jim Morton, Applix Inc., Westboro, MA jim(a)applix.com

1 0

Re: Support for Network Time Protocol?
by mer＠world.evansville.net 19 May '98

19 May '98

Another vote for NTP support. It doesn't need to be full-fledged -- client-only is fine. The rsh/rdate thing is a kludge. -- Marc Rouleau VP and Chief Technology Officer Voice: (812) 479-1700 Fax: (812) 479-3439 Network WCS http://www.networkwcs.com

5 4

As long as we're voting
by Amy Chused 19 May '98

19 May '98

I'd vote for NTP too. Amy Chused Server Administration GTE Internworking

1 0

Re: Support for Network Time Protocol?
by Chris March : TTSG : 781-393-3236 19 May '98

19 May '98

I'll add my vote to get support for NTP. Chris March Thomson Technology Services Group

1 0

Re: Support for Network Time Protocol?
by Don Glascock 19 May '98

19 May '98

> Another vote for NTP support. ... And another: we too have asked for NTP support, but have not heard when this will occur. Our toaster has fulfilled its charter well ("a box that encapsulates file service for NFS & CIFS clients") except in this regard: a file's modification time can be critical in certain situations, and therefore must be accurate. Don Glascock -- Donald S. Glascock Mailstop GU-1016 Special Purpose Processor Development Group Mayo Foundation Rochester, MN 55905 Glascock.Donald(a)Mayo.EDU +1.507.284.1850 +1.507.284.9171 (fax) http://www.mayo.edu/sppdg/sppdg_home_page.html "No matter where you go, there you are."

1 0

Re: syslog and /etc/messages format
by Mark D Simmons 19 May '98

19 May '98

(after with much rude elision) Jason wrote: > We currently use logsurfer and swatch to parse syslog messages > generated by our F330. We also use procmail to forward "critical" > email from the filer to alpha-pagers. We use swatch too. > There isn't an appendix which contains a _complete_ > list of all error messages and sample _syntax_ in the filer > documentation. Tech Support couldn't even get me a list of all the > possible email subject headers the filer might send in case of error! You know that's something that IBM and Digital used to do religiously, and it's in most good books on the subject of Technical Documentation. One wee book or greppable ASCII file on-line that contains the full gamut of error messages (even if what the message means is sanitised to 'phone NetApp' for some of the really weird ones) would be great. > So, I'm all for more specific messages -- as long as they are > documented. Please. Ditto.

1 0

Re: Support for Network Time Protocol?
by Mark D Simmons 19 May '98

19 May '98

We also asked for NTP support a while back. I've currently got all 9 main filers rdating to an NTP'd Unix box every hour and so far everything is okey, but proper NTP support would reduce the niggly tasks on the admin server and my confidence in the time on the filers. 2p

1 0

Re: Support for Network Time Protocol?
by Daniel Quinlan 19 May '98

19 May '98

Jason D. Kelleher <kelleher(a)susq.com> writes: > I recall asking about NTP over two years ago. Very disappointing. I'm also interesting in NTP support, but I think I'd like to see the current software become a lot more reliable (and complete) before adding another new feature. All I need is more NetApp crashes because of NTP bugs. Dan

1 0

Re: Support for Network Time Protocol?
by sirbruce＠ix.netcom.com 19 May '98

19 May '98

On 05/18/98 09:14:26 you wrote: > >sirbruce(a)ix.netcom.com wrote: >> Okay, I was just curious. Most places I've seen aren't as "religious" about >> the use of NTP. Not that there's anything wrong with that. :) >> >> Bruce > >NTP is integral to keeping the NYSE, SIAC, and Amex clocks in sync. We >use it on everything so that all trading is accurate on all systems to >within milliseconds of each other, which is crucial when billions of >messages have to be ordered, stored, processed, and then compared at the >end of the trading day. I can imagine! The demands there are much different from a college campus or a departmental server in a small corporation. Different environments need different solutions. I think all these posts are great - the more Netapp knows about customer desire for this, the more likely they are to implement the feature. It certainly seems more widespread than the last time I saw the question asked (although this mailing list doesn't exactly constitute a scientific survey). Bruce

1 0

NetApp File Server (FS230) mounted directly on an NT server
by Weeks, Thomas 18 May '98

18 May '98

I have a fairly good grasp on NT and CIFS and the like... but I am from the UNIX worls and just want someone to answer this for me once and all... Is there any way to MOUNT a NetApp file server directly to an NT file system and access it like unix does with a /mnt directory? I know about the menthod of mounting to NT via a drive letter... but you can't re-share that as a resource under that the NT file system CAN you? You know.. like this: given that NetApp box="\\barium\C$" and NT Server="\\ntbox" net use \\ntbox\shares\share \\barium\share net use \\ntbox\shares\winapps \\barium\winapps I know this is probably not possible.. but ya never know if you dont' ask.. it just seems that if the netapp box could be treated as a raw storage unit like this, that it would greatly simplify matters (regarding all the ACL problems). Anyone wanna tell me exactly why things can't be done like this? Thomas Weeks GTE SYSTEMS ENGINEER Testing-Integration Center "The Pit" Brooks AFB, DSN 240-5444

1 0

Exports file vs exportfs
by Alexei Rodriguez 18 May '98

18 May '98

In 4.x, NetApp added a feature such that one could do an export of a file system to a network (net/netmask) such that: exportfs -root=192.168.250.0/24 /export/test would allow anybody on the 192.168.250 network to get to /export/test on the filer. Cool. This works without a problem. What I am running into a hitch with is making this work out of the /etc/exports file. It just does not seem to want to work. Has anybody else worked with this notation out of the exports file? Did it work? Is the order of the hosts important (subnets before hosts)? Or am I simply missing something obvious? Thanks. Alex

1 1

Re: Support for Network Time Protocol?
by Jason D. Kelleher 18 May '98

18 May '98

In message <199805162033.NAA20194(a)paradiso.cnet.com>, John Caruso writes: >> Nothing religious about it, actually. We have a well established NTP >> infrastructure, we've used NTP for many years and are very comfortable >> with it. Thus we'd like to use it for NetApps too. > >Ditto. This seems to be on the "sometime in the future..." list for >Netapp, but we haven't heard of any definite plans. I recall asking about NTP over two years ago. Very disappointing. jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

1 0

NetApp as database storage - interface speeds?
by Thomson, Michael 18 May '98

18 May '98

Hi there. I've been asked to look at whether NetApp is a potential candidate for hosting some Oracle databases, but one thing I don't see is how to get sufficient sustained data rates between the Oracle server and the filer. We use 10 Base-T Ethernet and FDDI right now, 100 Base-TX Ethernet is coming onstream at present. Even connecting a filer direct to a server on private 100 Base-TX only gives 10 MBytes/sec, lots slower than Ultra-SCSI. If I'm going to use NetApp to host Oracle Databases I probably want more than one database server connected to a filer. I can only have one Gigabit Ethernet card per F630. So right now, I can't see a way to support more than one Oracle server from a single NetApp. Yours comments much appreciated as always. Cheers, Mike Thomson

2 1

Re: Support for Network Time Protocol?
by sirbruce＠ix.netcom.com 18 May '98

18 May '98

On 05/16/98 08:52:28 you wrote: > >> It is a little bit of a hassle, but rsh rdate works pretty well. Any reason >> why you don't want to use it? Do you use NTP for the rest of your environment? > >Yes. NTP for everything, including our Cisco routers. Keeps the time nicely, >and doesn't step it. It would be *much* nicer to have NetApp support use >NTP also. Okay, I was just curious. Most places I've seen aren't as "religious" about the use of NTP. Not that there's anything wrong with that. :) Bruce

2 1

Re: Support for Network Time Protocol?
by Alan Judge 18 May '98

18 May '98

Ditto here. We use NTP for everything else, machines, routers, even some Windoze PCs, ... It gives us accurate multi-machine logs that we can stand over (important for an ISP when people are accused of various sorts of misbehaviour). We also asked Netapp about NTP, but haven't had any definite statement yet. Even SNTP would do. -- Alan

1 0

HELP! CIFS and 4.3.4?
by Weeks, Thomas 17 May '98

17 May '98

Hey all... I was told, by just about everyone, that if I wanted full CIFS without the "backout problems" possible with 5.x, then I should just go to 4.3.4... Well.. I have.. and the major porblem I HAD with the NetApp implimentation of CIFS seems to still be there: It looks like while yes there is indeed NT server authentication happening now, no matter WHO I want to access the CIFS shares, they STILL have to MANUALLY PLACED into the /etc/passwd file!!!! What is the POINT of full blown NT server (domain) authentication if I STILL have to input ALL of the users into the /etc/passwd file! That's what my main problem is! We have TONS of UNIX users across campus who are on various NIS+ domains and as a result many have overlapping UIDs! i.e. we can NOT rely on single NIS+ uid mapping.. and would have the SAME problem if we tried to input all our users directly into a single /etc/passwd file on the server. Is the ONLY way to get around this is by going to 5.x? Does 5.x even FIX this serious problem? What about the differences in the 5.x file system? I don't HAVE a test file server to test this on.. 100% production... 8v/ Anyone here have this kind of expereince? Thomas Weeks GTE SYSTEMS ENGINEER Testing-Integration Center "The Pit" Brooks AFB, DSN 240-5444

2 1

Re: Performance problems
by sirbruce＠ix.netcom.com 17 May '98

17 May '98

On 05/14/98 15:19:12 you wrote: > > >How are the NICs on the F520 configured? How are the >switch ports configured? > >Make sure that the duplexes match on both ends. And, after checking that, I would double-check your setup in terms of routing. Perhaps configurations and netstat -r for each BSD system and filer would be helpful. Bruce

3 2

Re: Support for Network Time Protocol?
by sirbruce＠ix.netcom.com 17 May '98

17 May '98

On 05/15/98 14:39:03 you wrote: > >We recently observed some strange behavior due to the filer's clock being >about 1 minute and 30 seconds faster than a client's. The dates displayed >by 'ls -l' of files that had been recently created were listed as "May 14 >1998" instead of "May 14 18:22" like they should be. That is odd... I though ls did this only if the file was older than six months. I presume after 90 seconds it displays normally again, so I guess the ls in question isn't handling "in the future" times very well (it thinks they are in the past). >It is important that NFS clients and servers have the same time. We would >prefer to use NTP for time synchronization on the NetApp instead of running >a cron job on a UNIX server that will fire off a 'rsh rdate' command on the >filer. It is a little bit of a hassle, but rsh rdate works pretty well. Any reason why you don't want to use it? Do you use NTP for the rest of your environment? >Does anyone know about any NetApp plans to support NTP? I've heard a lot of people ask for it over the years but usually they move on to a different solution since HTP doesn't seem immediately forthcoming. Bruce

2 1

Re: Botched filer upgrade
by sirbruce＠ix.netcom.com 17 May '98

17 May '98

On 05/16/98 15:05:47 you wrote: > > >Hey folks. > >I just got some gigabit ethernet cards to replace my fddi >back-end network. The install went well (trivial) but all >release, non-5.x, DataONTAP versions have some bugs with >the gigabit ethernet. > >So, I upgraded to 4.3.4D2 which supposedly has the fix. >It works well on my f540. > >My f630 pukes horribly: > >Probing devices >Finding image... >Loading 14 f 5 disk@0 >Complete >Starting NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 >Copyright (c) 1992-1998 Network Appliance, Inc. > >PANIC: MM fault MMCSR=1, type=1, VA=0x79dba0, PC=0xfffffc00002a2d44 > > >version: NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 >cc flags: 1 >dumping core: Error dumping core --- not dumped. > >ok c > > >I quickly put the 4.3.3 boot floppy I had and we are back in service >and I am calming down.. :) > >So, anybody able to decode this error? It's a pretty brutal error that you probably can't do anything to fix. Since 4.3.4D2 is unreleased and a patch you got from support (I assume) particularly to address a Gigabit problem, then my guess it was never tested on a 600 series. So you really need to talk to tech support and let them know of the error and ask when a version of that will be available for the 600 series. :) Bruce

1 0

Re: Support for Network Time Protocol?
by sthaug＠nethelp.no 16 May '98

16 May '98

> >Yes. NTP for everything, including our Cisco routers. Keeps the time nicely, > >and doesn't step it. It would be *much* nicer to have NetApp support use > >NTP also. > > Okay, I was just curious. Most places I've seen aren't as "religious" about > the use of NTP. Not that there's anything wrong with that. :) Nothing religious about it, actually. We have a well established NTP infrastructure, we've used NTP for many years and are very comfortable with it. Thus we'd like to use it for NetApps too. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Botched filer upgrade
by Alexei Rodriguez 16 May '98

16 May '98

Hey folks. I just got some gigabit ethernet cards to replace my fddi back-end network. The install went well (trivial) but all release, non-5.x, DataONTAP versions have some bugs with the gigabit ethernet. So, I upgraded to 4.3.4D2 which supposedly has the fix. It works well on my f540. My f630 pukes horribly: Probing devices Finding image... Loading 14 f 5 disk@0 Complete Starting NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 Copyright (c) 1992-1998 Network Appliance, Inc. PANIC: MM fault MMCSR=1, type=1, VA=0x79dba0, PC=0xfffffc00002a2d44 version: NetApp Release 4.3.4D2: Wed May 13 07:55:56 PDT 1998 cc flags: 1 dumping core: Error dumping core --- not dumped. ok c I quickly put the 4.3.3 boot floppy I had and we are back in service and I am calming down.. :) So, anybody able to decode this error? My filer is: whirlpool> sysconfig -v NetApp Release 4.3.3: Mon Mar 16 12:58:27 PST 1998 System ID: 0016786960 slot 0: System Board (NetApp System Board IV rev-b) Firmware release: 1.8_a1 Memory Size: 512 MB slot 2: Ethernet Controller e2 (Znyx) MAC Address: 00:c0:95:f8:2f:6d (Twisted pair) slot 3: FDDI Network Adapter f3 (DEC 3002) MAC Address: 00:00:f8:bd:c6:04 (Dual Attach Fiber) slot 8: Dual SCSI Host Adapter (NetApp SCSI Adapter I) SCSI Host Adapter 8a (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 1: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 2: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 3: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 8: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 9: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 10: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 11: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 12: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) EMU 0: P/N 500408 S/N 2550270236 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events EMU 1: P/N 500408 S/N 2550272530 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events SCSI Host Adapter 8b (Qlogic ISP 1040B) Firmware Version 2.26 Clock Rate 40MHz. 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 1: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 2: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 3: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 9: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 10: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 11: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) 12: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) EMU 2: P/N 500408 S/N 2550272276 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events EMU 3: P/N 500408 S/N 2550272259 Firmware Rev 1.19 0 Swap Events, 0 Enclosure Events slot 9: NVRAM (NetApp NVRAM II) Revision: A1 Serial Number: 9744 Memory Size: 16 MB Battery 1 Status: 100% (3.30v) Battery 2 Status: 100% (3.29v) slot 10: Gigabit Ethernet Controller e10 MAC Address: 00:60:cf:20:48:61 (1000fx) whirlpool> I need gigabit pretty badly but don't want to go to 5.x yet. Anybody? Thanks. Alex

1 0

Re: Support for Network Time Protocol?
by sthaug＠nethelp.no 16 May '98

16 May '98

> It is a little bit of a hassle, but rsh rdate works pretty well. Any reason > why you don't want to use it? Do you use NTP for the rest of your environment? Yes. NTP for everything, including our Cisco routers. Keeps the time nicely, and doesn't step it. It would be *much* nicer to have NetApp support use NTP also. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Calculating increase in used space when moving to a filer (long)
by Keith Brown 15 May '98

15 May '98

>I'm about to move data from an old&creaking NT server to a F230. >Iwas aware that moving to the filer would lead to a space usage >increase due to the larger block size (4K as against 512bytes for >standard NTFS) This is not necessarily the case, and almost certainly wouldn't be the case for most installations/migrations. "Standard NTFS" would very *rarely* be using an allocation unit size of 512 bytes on most modern systems. The way NTFS figures out the default allocation unit size to use on a particular disk or volume-set is quite simple, if you can remember the "kilobyte to gigabyte" correlation that exists. Specifically, NTFS uses an allocation unit size of half a kilobyte on disks of half a gigabyte or less (rare these days, right? :-)), one kilobyte on disks of one gigabyte or less, two kilobytes on disks of 2 gigabytes or less, and 4 kilobytes thereafter. Unless you manually created your NTFS file systems using something along the lines of a: C:\> FORMAT d: /fs:ntfs /a:512 to override the default and force an allocation unit size of 512 bytes, then your NTFS file system will likely be using the same default allocation unit size as WAFL uses (4Kb). Also, don't forget the swings-and-roundabouts issues that are normally associated with small AU sizes. There's a reason that AU sizes generally get bigger as file system sizes increase. Smallers AU's cause most file systems to burn more AU's to keep track of the AU's, if you see what I'm saying? :-) It is often hard at best, and impossible at worst to accurately account for such matters in application level scripts that just read "visible stuff", but I don't think that you'll find that WAFL and NTFS are fantastically different space burners for the vast majority of situations.* If you do, well.... let me know, *especially* if WAFL proves far superior.... :-) Keith

1 0

Support for Network Time Protocol?
by Mike Mueller 15 May '98

15 May '98

We recently observed some strange behavior due to the filer's clock being about 1 minute and 30 seconds faster than a client's. The dates displayed by 'ls -l' of files that had been recently created were listed as "May 14 1998" instead of "May 14 18:22" like they should be. It is important that NFS clients and servers have the same time. We would prefer to use NTP for time synchronization on the NetApp instead of running a cron job on a UNIX server that will fire off a 'rsh rdate' command on the filer. Does anyone know about any NetApp plans to support NTP? -- Mike

1 0

Re: syslog and /etc/messages format
by tjt＠netapp.com 15 May '98

15 May '98

> for one reason. There isn't an appendix which contains a _complete_ > list of all error messages and sample _syntax_ in the filer > documentation. ... > So, I'm all for more specific messages -- as long as they are > documented. Please. Thanks for the input. Yes, it's our intention that unique message ids be usable for looking up information about the messages, implying that there is a database of all messages that can used in a variety of ways, including documentation. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

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