toasters

toasters@lists.teaparty.net

1 participants
13514 discussions

CIFS directory conversion of NFS created files
by Todd C. Merrill 17 Mar '99

17 Mar '99

This from the docs for ontap 5.2.1: file://....5_2_1-cd/ontap/5_2_1/doc/html/sag/multi5.htm#1180418 Timing of directory conversion for CIFS access to NFS-created files [...] One-time access conversion If you add CIFS access to files that were created by NFS clients, the first time a directory is accessed through CIFS, the filer automatically converts it to the format required to support CIFS clients. "Accessed" here includes listing the contents of a directory; for example, with the File Manager, Explorer, or DOS dir command, or by accessing any files or directories contained in that directory. Under some circumstances, the CIFS client might automatically look at the directory's subdirectories, thereby triggering conversion of the subdirectories as well. (For example, this happens if the user has set the Expand All option under the File Manager Tree menu.) After a directory is converted, it does not have to be converted again. Here's my question(s): I have a directory on the filer root (at the level of etc) called "devel." Under that is a tree called "tree." A CIFS share is defined on "tree." Under "tree" is a bunch of other directories: devel/tree/{dir1,dir2,dir3,...dirN} When I first got the filer, I did a right-click:properties from an NT box on all directories dir1,dir2,...dirN in order to force the conversion process recursively. Things have been running smoothly. Until yesterday. The darn "access is denied" error message on the NT box is showing up again under the nightly snapshot for this tree on some directories. I suspect the directories are new, but have been renamed to previously named directories. (I.e., `mkdir new; mv dir old; mv new dir; rm -rf old` might have happened from an NFS mount). Question1: If I create a new directory devel/tree/dirnew and put some stuff in it, and no NT box access it before the nightly snapshot, this directory will give an "access denied" message to any NT box trying to access this directory from the snapshot, right? (I believe the answer is "yes" since this seems to jive with empirical data.) Question2: If I define a share at "devel" and then convert the entire *tree* directory, instead of dir1,dir2,...dirN, will any subsequent directory created under that tree (at the level devel/tree/dirnew) already automatically be converted, since its parent was? (This is kinda like the old SunOS subdirectories inheriting the group (?) owner of the parent.) (I think the answer is no, from FAQ#486). Question3: If the answer to #2 is no, is there another way to make this happen automagically? It seems reasonable, especially if a share is defined on any directory higher in the tree. 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

RE: filer NFS to hp700 or alpha: client cache problem?
by Thomson, Michael (UK, GIS ISM Group for R&D) 17 Mar '99

17 Mar '99

Todd, Could I suggest you check the time synchronisation between your client box (doing the linking) and the Filer? In a previous life I found that 'make' and other tools ignore files if their creation dates are in the 'future', even if it's only a few seconds to a minute. I suspect that might explain why depending on how quickly you run the 'rm', only 2/3 or all the files vanish. Now, all together: "Please can we have Network Time Protocol support on our filer?" Cheers, Mike > -----Original Message----- > From: Todd C. Merrill [SMTP:tmerrill@mathworks.com] > Sent: Tuesday, March 16, 1999 10:43 PM > To: toasters(a)mathworks.com > Subject: filer NFS to hp700 or alpha: client cache problem? > > > We haven't narrowed down the problem entirely yet, but I'd thought I'd > ask anyway.... > > During a linking stage, in linking a bunch of .o files into a library > .a, the linker will grab about 2/3 of the files in a directory into the > archive, and that's it. A subsequent `rm` of *.o sometimes removes only > those exact 2/3 files, sometimes removes all of them, even though the > archive only has 2/3 of them in it. > > It seems as if the directory inode is only showing the oldest 2/3 of the > files, and depending on how long it takes the `ar` and `rm` commands to > execute, removes 2/3 or all of the files. > > I don't suspect it's the filer; watching an `ls` of the directory from > another machine (Solaris) shows all the files there. There are only > about 150 .o files to archive. > > Anyone aware of any client-side NFS caching problems with Alpha or HP700 > boxes? The HP is running HPUX10.20 and appears to be using only NFS V2; > the alpha is running Digital UNIX V4.0D and appears to be using only V3. > (NFS version from `nfsstat -h hostname` on the filer.) The filer is set > nfs.tcp.enable off, NetApp Release 5.2.1. > > 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 > ---

2 1

Backups from DUMP command and snapshots
by Mike Ball 17 Mar '99

17 Mar '99

Questions Please understand I am a novice to the "dump" command when answering the following questions. Thank you for the help! 1) From what I understand running, a full backup with the "dump" command does not backup existing snapshots. Is this correct? 2) It looks like if you want to backup snapshots, you must backup a particular snapshot one at a time. Is this correct? 3) If I do a full restore (if the file system on the filer completely crashed) from a backup created by the "dump" command on the filer, it looks like I must first create the exact qtree structure which was previously on the filer before I can run the full restore. Is this correct?

2 1

filer NFS to hp700 or alpha: client cache problem?
by Todd C. Merrill 17 Mar '99

17 Mar '99

We haven't narrowed down the problem entirely yet, but I'd thought I'd ask anyway.... During a linking stage, in linking a bunch of .o files into a library .a, the linker will grab about 2/3 of the files in a directory into the archive, and that's it. A subsequent `rm` of *.o sometimes removes only those exact 2/3 files, sometimes removes all of them, even though the archive only has 2/3 of them in it. It seems as if the directory inode is only showing the oldest 2/3 of the files, and depending on how long it takes the `ar` and `rm` commands to execute, removes 2/3 or all of the files. I don't suspect it's the filer; watching an `ls` of the directory from another machine (Solaris) shows all the files there. There are only about 150 .o files to archive. Anyone aware of any client-side NFS caching problems with Alpha or HP700 boxes? The HP is running HPUX10.20 and appears to be using only NFS V2; the alpha is running Digital UNIX V4.0D and appears to be using only V3. (NFS version from `nfsstat -h hostname` on the filer.) The filer is set nfs.tcp.enable off, NetApp Release 5.2.1. 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 ---

4 3

RE: Etherchannel (was Re: NetApp/Auspex killer?)
by Mohler, Jeff 16 Mar '99

16 Mar '99

FYI here is what I have on EC on the NA. *heh* <<TRUNKING.html>> > -----Original Message----- > From: Bennett Todd [SMTP:bet@newritz.mordor.net] > Sent: Tuesday, March 16, 1999 11:48 AM > To: tkaczma(a)gryf.net > Cc: toasters(a)mathworks.com > Subject: Etherchannel (was Re: NetApp/Auspex killer?) > > 1999-03-16-02:01:42 Tom: > > Speaking of EtherChannel or more generically Link Aggregation. Does > > anyone know a link describing it in quite a detail without going through > a > > complete protocol suite definition. > > Don't know of a link, would love to see one. But as I understand it, the > general strategy is that very roughly each side separately runs simple > algorithms to attempt to schmeer traffic over the multiple links. Often > the > algorithm is based on the MAC addrs of the two endpoints, and so won't > yield > over 100Mbps for any single link, but will hopefully (3 times out of 4) > place > competing high-volume connections on separate links. > > There are then hacks for failing over to another line when one link drops, > and > other border-condition exotica. > > But the basic idea is that given a large number of communication > endpoints, > you can schmear the traffic over multiple links quite cheaply. > > Dunno if this is any help to you. > > -Bennett

1 0

Re: BDC/NAC issues
by Mark Muhlestein 16 Mar '99

16 Mar '99

Not true. If a BDC the filer is talking to goes away the filer will just attempt to connect with another one. If the "NAC people" are NetApp employees, please let us know who they are so we can give them the correct information. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Graham C. Knight <grahamk(a)ast.lmco.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Tuesday, March 16, 1999 10:13 AM Subject: BDC/NAC issues >Someone just posted this message to just about >every top level manager in our company :-( > >> >> What I am hearing 2nd hand is that NAC people say that the NAC's get locked >> into a BDC for authentication. >> If that BDC goes away or gets renamed that all the NACs will need to be >> removed from server manager, CIFS will have to be reconfigured, and then >> they will have to be added back into the servers Domain. >> >> If this is true then we have no unattended failover capabilities for a BDC >> dying. This could be a significant problem. > > >So - is this true? I don't know enough about NT to comment... > >TIA, > Graham

1 0

BDC/NAC issues
by Graham C. Knight 16 Mar '99

16 Mar '99

Someone just posted this message to just about every top level manager in our company :-( > > What I am hearing 2nd hand is that NAC people say that the NAC's get locked > into a BDC for authentication. > If that BDC goes away or gets renamed that all the NACs will need to be > removed from server manager, CIFS will have to be reconfigured, and then > they will have to be added back into the servers Domain. > > If this is true then we have no unattended failover capabilities for a BDC > dying. This could be a significant problem. So - is this true? I don't know enough about NT to comment... TIA, Graham

1 0

Any comments on emergin SANS technology...
by Christoph Doerbeck A242369 16 Mar '99

16 Mar '99

Just wondering if anyone on the list has an opinion on Storage Array Networks (SANS)... Should NetApp try to develop another product line for SANS based on WAFL? I don't know enough about the underlying technology to make any clever or intelligent comments. - Christoph

1 0

5.2.1D5: praise and a caveat
by Brian Rice 16 Mar '99

16 Mar '99

Last Friday night I put 5.2.1D5 (the successor to 5.2.1P1) on one of the F630's. It didn't panic, and I've got my quotas back. Ahhhh, yeah. Just one leetle caveat, one which caused me to believe I had a hung filer and to place a down-filer call to NetApp technical support. It seems that 5.2.1D5 sets the floppy-boot? environment variable for you by default. So when you boot, you see something like... NetApp Release 5.2.1D5: Mon Mar 8 23:54:01 PST 1999 Copyright (c) 1992-1998 Network Appliance, Inc. Starting boot on Sat Mar 13 07:50:19 GMT 1999 Scanning for disk drives: floppy boot? .......................... Spinning up disk drives: 8a.12 8b.12 8a.13 8b.13 8a.14 8b.14 Configuring disk drives: 8b.14 8a.14 8a.9 8a.12 8b.11 8b.12 8b.9 8b.8 8b.4 8b.5 8b.1 8a.3 8a.10 8a.2 8a.11 8a.5 8b.0 8b.10 8b.13 8b.2 8b.3 8a.13 8a.8 8a.1 8a.0 8a.4 and then, apparently, the filer hangs, with the LCD saying "Configuring disk 8a.4" (or whichever one was last). Turns out that that "floppy boot?" way up there at the top was a prompt. It's waiting for you to type "yes" or "no" on the console. A "no" causes the boot to finish normally. Then a "setenv floppy-boot? false" and a reboot gives you a happy filer. Thanks to the NetApp tech support guy for reacting so graciously to being beeped in the middle of his Friday night. Brian

3 3

Re: NetApp/Auspex killer?
by Darrell Fuhriman 16 Mar '99

16 Mar '99

discussing hardware completely ignores the core of what makes the Netapp so good -- the file system. WAFL simply beats all the others -- even ext2 or veritas. Darrell

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