toasters

toasters@lists.teaparty.net

13513 discussions

Re: Nitech XRP1000 filer
by sirbruce＠ix.netcom.com 26 Feb '99

26 Feb '99

On 02/25/99 08:34:50 you wrote: > > > >>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> > >>> To open a real can-of-worms, what would people on this list like to see in >>> a low-end product offering? (Sub-$10k chassis). > >>This hypothetical discussion would be of great interest to me. :-) > >I'll take a crack at it: > >PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) >Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) >256 MB RAM >4-8MB NVRAM >Single 10/100 Ethernet >Single SCSI Bus >Up to 7 9GB (or larger?) disks >A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. > >Make it one box, disks and all. I thought they already did this. It was called the F210. :) My personal experience with those admins who are "cheap" either by nature or by force is that such a small box doesn't appeal to them for a variety of reasons. They don't need high-performance at that end of the scale, so they can cobble together a server with cheaper ethernet cards and disks that work "just as well". They may not get RAID, but they rarely need it. Then the inevitable happens... they want to add more disk that it can take. They feel resentful that they can't add more disk, even though they think the CPU can handle it. The have no qualms about stringing 21 drives off an old Pentium with an ISA ethernet card if they can get away with it. And of course they want to use *their* cheap disk, not what Netapp wants for the performance. And then when the load gets too great or it crashes, they want to blame the vendor(s) and netapp. And then they get resentful if you tell them they have to upgrade the whole server to handle the increased load of the increased disk and users... they want to just put in more memory, or swap the CPU, and be done with it! I'm not saying Netapp can't make some more inroads into the low-end. I think they can and will, eventually. But there's a large contigent out there who always think they can get away with doing it cheaper by putting together their own linux box with a bunch of disks. Sometimes they can get away with it; sometimes they can't. If netapp can design a low-end box that uses cheaper components and perhaps has optional RAID but still at reasonable (not great) performance, they might be able to make some headway. But the margin will be small. Bruce

3 2

atime updates - OT 5.1.1 / NFS / FreeBSD
by Brett Rabe 26 Feb '99

26 Feb '99

Greetings. Is it the correct NFS behavior for non-uid-0 users opendir() calls to not update st.st_atime, but uid-0 opendir() calls to do so? I've got a filesystem mounted from the NetApp to the FreeBSD machine, exported as: /vol/vol0/home -access=client_hostname,anon=0 It's mounted on the client rw,intr,nfsv2. When I run a program as uid 0 that does simply an opendir()/closedir() on a directory, the directory's st.st_atime gets updated. When I run the same program as uid > 0 (in this case, 51, to be exact), atime does not get updated. I'm obviously missing my NFS roll here. Whassup with that? Shouldn't client requests as non-uid 0 also update atime? (Because I know somebody will ask, no_atime_update is not set on the volume. :) ) Am I just plain not understanding the man pages? Brett --- Brett Rabe Email : brett(a)uswest.net Systems Administrator - U S West Phone : 612.664.3078 Interact - 3S Pager : 612.613.2549 600 Stinson Blvd. Fax : 612.664.4770 Minneapolis, MN 55413 USA Pager : page-brett(a)uswest.net Bombs don't kill people. Explosions kill people.

2 2

Re: Nitech XRP1000 filer
by Tony Paolucci 25 Feb '99

25 Feb '99

>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> >> To open a real can-of-worms, what would people on this list like to see in >> a low-end product offering? (Sub-$10k chassis). >This hypothetical discussion would be of great interest to me. :-) I'll take a crack at it: PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) 256 MB RAM 4-8MB NVRAM Single 10/100 Ethernet Single SCSI Bus Up to 7 9GB (or larger?) disks A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. Make it one box, disks and all. Don't worry about hot-swap or hot spare disks. If you're buying at this end of the market, down time probably costs you less than it does the big-boys. Instead, sell a cold-spare disk which sit on the shelf until they need it. If it saves mfg costs, solder the memory, nvram & ethernet to the motherboard. Ship a single config. With a max usable of +/- 50GB a box like this could be a departmental fileserver, or a NetCache box for small to medium organizations who don't need/want a big NetApp for the job. I don't know how close this comes to the $10K figure. It's probably closer to $20K maxed with disks. Still, that's my .$.02 worth Tony Paolucci System Administrator, Growth Management, Metro, Portland, Oregon

3 2

Re: budtool 4.6 / ndmp /restore
by dnb＠ccs.neu.edu 25 Feb '99

25 Feb '99

Douglas Ritschel <djr(a)research.bell-labs.com> writes: > We seem only to be able to restore files, that were backed up from our > Netapp 760 filer, to their original location on the Netapp. If I try to > restore a file to a different location on the Filer, than the location > that it was backed up from, I receive an error message saying that the > machine is not running ndmp. And the restore fails. > > Does anyone have experience with this? We had some interesting restore problems until we found out that you must create an "etc" directory at the top of each of your volumes (at least in 5.1.2* with Budtool 4.6). The filer will then create a "tmp" dir for you in that etc dir and use it as a staging area for your restore. Fascinating, no? Peace, dNb

3 2

budtool 4.6 / ndmp /restore
by Douglas Ritschel 25 Feb '99

25 Feb '99

We seem only to be able to restore files, that were backed up from our Netapp 760 filer, to their original location on the Netapp. If I try to restore a file to a different location on the Filer, than the location that it was backed up from, I receive an error message saying that the machine is not running ndmp. And the restore fails. Does anyone have experience with this?

2 1

RE: Net App and NetBackup
by Daisy Nguyen Davis 25 Feb '99

25 Feb '99

I DO NOT recommend Budtool! I have been using Budtool in the last 4 years. From the beginning, the support was wonderful even though the product was just so so. But since Budtool splits into 2 companies: budtool and Intelliguard, I have had many bad experiences with both product and support from Intelliguard. Many of their experience tech supports are gone. The new ones are nasty and inexperience. In my opinion, the product is not worth the headache. Daisy --------------------------------------- From: "Raymond Brennan" <ray_brennan(a)mentorg.com> Subject: RE: Net App and NetBackup MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199902251256.NAA15704(a)uabs78c65.uab.ericsson.se> Sender: owner-toasters(a)mathworks.com Precedence: bulk X-Mozilla-Status2: 00000000 part text/plain 619 Press <return> to show content... I have been using Budtool from Intelliguard and can heartily recommend it-very stable, very easy to use and well supported. Raymond >-----Original Message----- >From: owner-toasters(a)mathworks.com >[mailto:owner-toasters@mathworks.com]On Behalf Of Michael Salmon >Sent: Thursday, February 25, 1999 12:57 PM >To: toasters(a)mathworks.com >Subject: Net App and NetBackup > > >I wondered if anyone was using NetBackup with their filers. We are >currently using Networker but are sufficiently dissatisfied that we >going to look at NetBackup and I am interested in any problem that >others have encountered. > >/Michael >

5 6

Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 25 Feb '99

25 Feb '99

On the evening of Saturday February 20 we upgraded from BudTool 4.5 to 4.6. Since then, we've not been able to do local NDMP backups on our filer. Anyone out there experience similar problems? If so, would you please throw some suggestions my way. We have support calls open with both NetApp (being very helpful considering it's probably not an issue with their system) and Intelliguard (with what we pay them I'd assume they could at least hire warm bodies). Here's what we've come up with so far: 1) Intelliguard told us to add the line "ROBOT_SCSI_LUN 1" to the jbmgr_config for the filer. This allowed the jbmgr daemon to start. audreyii: /usr/budtool/bud [225] % cat jbmgr_config.audreyii.2 ROBOT_DEV_HOST nfssrv1 ROBOT_DEV_NAME spt0 ROBOT_SCSI_ID 2 ROBOT_SCSI_BUS 2 ROBOT_SCSI_LUN 1 DATA_DEV_NAME0 nrst0a DATA_DEV_HOST0 nfssrv1 PASSWORD xxxxxxxx USEBARCODE N VALIDATECMD "$BTHOME/bin/jbupdate audreyii:2 -a" audreyii: /usr/budtool/bud [226] % 2) Running the BudTool probe-scsi command shows the devices: audreyii: ~ [230] % probe-scsi -h nfssrv1 Copyright (c) 1990-1999 by Intelliguard Software Inc. probe-scsi BudTool 4.6 SCSI Bus 0 SCSI Bus 1 SCSI Bus 2 Target 2 Unit 0 Removable Tape EXABYTE EXB-8500 CC37 Unit 1 Removable Jukebox Device EXABYTE TZ Media Changer CC37 SCSI Bus 3 SCSI Bus 4 audreyii: ~ [231] % 3) After placing 2 labled BudToool tapes into the jukebox, running jbupdate returns instantly showing no tapes in the jukebox (doesn't even attempt to read tape labels). audreyii: ~ [236] % jbupdate audreyii:2 -a ------------------------------------------------------------------ ------ W A R N I N G ------- You have selected to force an update on all 5 tapes. This process requires several minutes per tape for unbarcoded tapes. Large jukeboxes with unbarcoded tapes can take several hours. The PID of this process is 8721. Use a HUP, INT, TERM or QUIT to terminate this process if you do not want to continue. ------------------------------------------------------------------ Update complete. audreyii: ~ [237] % jbmgr -H audreyii:2 ls -a 0: 1: 2: 3: 4: audreyii: ~ [238] % 4) We can perform remote NDMP backups to our BudTool master media server, but this isn't practical at ~2.2 GB/hr with 70+ GB on our filer. (It's an old, slow F330 which I'm supposed to be replacing instead of trouble-shooting...) 5) Gave Intelliguard a copy of our config file, the jbmgr diag log, and the probe-scsi output for analysis. The diag file does show some errors: 6) After not receiving much help from Intelliguard, we called NetApp. They sugggested we upgrade from 5.1.2P2 to 5.1.2R3P1 to remove the possibility that this was related to an NDMPD bug (6417). 7) Spoke to Intelliguard again Monday and informed them that we were going to upgrade the filer. We decided to see if the upgrade solved the problem. (They managed to fix a btcp issue after I waited 4 hours for a call back -- I'm still waiting for our sales rep to tell me exactly what kind of turn around to expect when paying extra for 24x7 support.) 8) Nothing changed after the upgrade Monday night. I informed NetApp; they opened another call and had us send them more info. 9) Told Intelliguard, gave them another copy of the diag file. 10) Configured BudTool to do lev 1 remote backups of the filer, this should hold us until the weekend. 11) Had to take a personal day Tuesday (for personal reasons). Hoped I get a couple voice/e-mails telling me that someone figured out what was wrong. (Finding out we were stupid and didn't have BudTool configured correctly would have been a relief.) 12) Wednesday we received some follow-up calls from NetApp, the call was escalated, and we're currently expecting a call. 13) We verified that tapes can be manually loaded into the jukebox drive and dump run on the console of the filer. Pretty confident that the jukebox didn't coincidentally die during the BudTool upgrade. 14) Will file missing persons reports for Intelliguard employees in another 24 hours. (Anyone have the number for the police in Dublin, CA?) So far, I'm confident it's a BudTool issue. (Many thanks/apologies to NetApp if it is.) I'd be very grateful if someone could give me a possible avenue of investigation. I'm at a dead-end and looking at over 30 hours of backups to lev 0 our filer this weekend... :( thanks, jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

2 1

Re: Shared Snapshot directory
by Daniel Quinlan 24 Feb '99

24 Feb '99

Dave Hitz <hitz(a)netapp.com> writes: > It remains to be seen whether or not we're crazy, but perhaps > I can convince you that we're not *completely* crazy. > > I understand your skepticism, because running the entire backup data > flow through Java would probably not result in acceptable performance. > > Our idea is to use Java to execute the Legato daemons, and to direct > the data movement, but to provide new primitives in WAFL that allow > Java to say things like: "stream the data from this inode to this > network connection." I'm not sure what all WAFL primitives Jim ended up > adding to boost performance, but hopefully you get the idea. We're not > talking about the normal Java I/O library here. > > So Java orchestrates the backup, but the data flow itself goes directly > from WAFL to the network, using the same basic code path as NFS, CIFS > or HTTP. Dave, This seems like marketing-deal-driven engineering. A backup system that requires every client to run a specialized daemon (which must be ported every time you want to use a new type of client) seems really broken to me. We're quite happy here using dump, restore, and (nowadays) NDMP. I'm worried that these additions will not only cause us problems on our filers, but will encourage Legato to kill off BudTool. Most of all, I don't really understand the effort being applied to Java/Legato when other simple, useful, and important protocols like SNTP, SNMP, and rsh are unsupported or neglected. - Dan

2 1

Too many open files...
by yrsuser 23 Feb '99

23 Feb '99

I have an F230 that is lightly used (relatively speaking) with NFS and CIFS enabled, and HTTPD - but no real web stuff on it yet. It's running 5.1R1 - and has been up for about 110 days. A few days ago, I started getting the following error, which shows up once a minute in the /etc/messages file: [httpd_log_main]: can't open /etc/log/httpd.log: too many open files I'm not seeing any other problems - my users are not having trouble getting to things in their home directories (primarly what we have on the F230). No disk errors, scrub errors, or other warnings in the logs. Is there a simple solution? I'd rather not have to reboot unless it becomes a real problem. I'm waiting for delivery of the current version of the OS, and will need to reboot to install that anyway. Cliff

1 0

cifs shares -delete ... {-force ?}
by Todd C. Merrill 23 Feb '99

23 Feb '99

There doesn't appear to be a "force" option to the `cifs shares -delete` command, that is available via an rsh: # rsh bat-toaster cifs shares -delete R12 The share R12 cannot be deleted; users are currently using it. However, if I do this on the console, it prompts me: bat> cifs shares -delete R12 Users have open files on R12. Continuing the operation will force the files closed. Do you want to continue this operation? [no]: yes and the share can be forcibly deleted. I need to be able to do this programmatically via an rsh command; the man pages for cifs_shares show no such option (forcegroup doesn't seem appropriate). Help! toaster info: R12 /vol/vol0/devel/R12 everyone / Full Control Files are open with both Exec-denyW and Read-denyN. NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998 Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.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