toasters January 1999

toasters@lists.teaparty.net

71 participants
68 discussions

Re: Snapshots/no snapshots on the same volume
by Keith Brown 21 Jan '99

21 Jan '99

>Can you designate a certain area of the same volume to not snapshot >where you designate the rest of it to do so? No. Sorry. Keith

3 2

Clustered failover product roadmap
by Brian Tao 20 Jan '99

20 Jan '99

I've got two conflicting pieces of information that I'd like to have sorted out. I initially thought that clustered failover was available on the F760 late last year, and that it was coming to the F740 sometime this quarter. I was then told by a Netapp vendor that last year saw the rollout of clustering on the F630's, and that I should only expect clustering on the F760's this quarter. Clustering on the F740's was not in the plans. I'm pretty sure I heard right the first time, and I'm told Netapp demonstrated an F740 cluster at LISA'98. I bought a pair of F740's on the assumption that I could get clustering on them for 1999Q1, and I'm about to buy another pair on the same assumption. -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

4 3

Snapshots/no snapshots on the same volume
by Bob Collie 20 Jan '99

20 Jan '99

Can you designate a certain area of the same volume to not snapshot where you designate the rest of it to do so? It is my current understanding that I have to create an entirely new volume in order to try and do this, but I'm hoping that is not the case. NetApp Release 5.1.2: Sat Sep 26 05:05:59 PDT 1998 Thanks, -Bob -- Bob Collie, VP/Chief Technical Officer, Telalink Corporation mailto:bob.collie@telalink.net

1 0

RE: Clustered failover product roadmap
by Gegenheimer, Bill 20 Jan '99

20 Jan '99

You may get multiple responses on this one. Clustering on the 760's and the 740's is supported now, as of release 5.2.1, which has just come out (last week). Bill > -----Original Message----- > From: Brian Tao [mailto:taob@risc.org] > Sent: Wednesday, January 20, 1999 12:26 PM > To: toasters(a)mathworks.com > Subject: Clustered failover product roadmap > > > I've got two conflicting pieces of information that I'd like > to have sorted out. I initially thought that clustered failover was > available on the F760 late last year, and that it was coming to the > F740 sometime this quarter. I was then told by a Netapp vendor that > last year saw the rollout of clustering on the F630's, and that I > should only expect clustering on the F760's this quarter. Clustering > on the F740's was not in the plans. > > I'm pretty sure I heard right the first time, and I'm told Netapp > demonstrated an F740 cluster at LISA'98. I bought a pair of F740's on > the assumption that I could get clustering on them for 1999Q1, and I'm > about to buy another pair on the same assumption. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >

2 1

Re: can't control access over CIFS
by Keith Brown 20 Jan '99

20 Jan '99

>Clearly, there is some cacheing going on, but I don't know where, why, >or when. Yes there is some "cacheing" going on, and this is probably what's causing your confusion. When a Windows client first establishes a CIFS session to the filer, either by mapping a network drive to a filer share or by accessing our file system using a UNC pathname, the Windows user is normally mapped to a valid UNIX identity so that the UNIX permissions in the file system can be enforced on that user. This is done by looking up the Windows username in the filer's /etc/passwd file (or the equivalent passwd.byname NIS map) and associating the users UNIX UID, primary GID and secondary GIDs with the established CIFS session (the secondary GIDs, if any, come from an /etc/group lookup, just like on UNIX). This mapping only occurs at session establishment time. If you subsequently add the user to another group by editing the /etc/group file, or change their UID or primary GID by editing the /etc/passwd file, the new values and/or group memberships will not be associated with the Windows user until they disconnect their session from the filer and then reconnect. Forcing a Windows client to disconnect a CIFS session from a server is actually something of an art form. The CIFS redirector on Windows manages sessions largely independently of direct user actions, and this may also be causing some confusion. For example, a: NET USE Q: \\FILER\SHARE will establish a CIFS session to the filer (unless there is one established already), but a: NET USE Q: /D will not disconnect the session. It will disconnect the network drive from the CIFS session (you won't have a Q: anymore), but the CIFS session itself will normally remain established, even if you have no other drives mapped to the filer. Only if you don't try and access the filer via *any* method (UNC or mapped drive) for a period of time (10 minutes is the default, but it can be changed in the registry) will the CIFS redirector quietly disconnect the session from the filer. This is just how Windows networking works, whether you're dealing with a filer or a Windows NT server. So, if you mess with a Windows user's group memberships by editing the passwd and group databases, the easiest way to make *certain* that a new mapping is done immediately is to force a disconnect from the filer side using the "cifs terminate <workstation-name>" console command. I'm fairly certain that logging the user out of the Windows client and then logging them back in again will force a client side disconnect, but I haven't watched that one with my own eyes and I don't want to mislead you. The Windows redirector's session management policies can be a little esoteric. :-) Whatever you do, you can use the "cifs sessions" command to make sure that the client's session has gone before you try accessing the filer again from said client after making the changes. As a final note, this mapping-Windows-users-to-equivalent-UNIX-users stuff is actually unnecessary if you are using the filer in a Windows-only context. If you enable NTFS security within our file system, Windows users do not have to be associated with unique UIDs and GIDs etc... in order for security to be enforced. In other words, Windows-centric folk should not be "scared" by any of the above. If you don't care about UNIX, none of this is necessary or directly applicable. If you just have a mass of humble Windows users, we don't "force" you to mess with passwd files, group files, UIDs, GIDs, UNIX perms etc, etc... to administer these users. It can all be done using regular domain accounts and NTFS permissions, all managed and administered from the standard User Manager for Domains and Server Manager NT tools, as well as the Explorer UI (file properties -> security -> permissions etc...). Keith

1 0

Frequency of "recovered error" messages
by sthaug＠nethelp.no 20 Jan '99

20 Jan '99

We have an F330 running 4.3.3D2 where one of the disks is now generating 30 - 40 "READ sector xxxxxxx recovered error" messages per day. At what frequency of such messages should I start worrying about the disk? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 2

Sybase or Oracle on NetApp?
by Adam Moskowitz 20 Jan '99

20 Jan '99

Is anyone out there running Sybase or Oracle on top of your filers? Are you satisfied with the performance? Have you had any problems? Any tips. We're considering doing this for our Sybase applications (which are closer to data warehousing than OLTP, if that matters). Please respond to me and I'll summarize to the list. Thanx, AdamM

1 0

Problem restoring files
by charles＠applix.com 19 Jan '99

19 Jan '99

This question probably has an obvious answer, but here goes: We are trying to restore a particular sub-directory from a single tape backup. Since I have never done this, I ran the command "restore tf nrst0a fran" to make sure that the syntax was right. This listed all of the files in the target directory (/user/fran). But when I went to do the actual restore ("restore rvf nrst0a fran"), I started getting messages like "Warning: cannot create directory /user/miller/blah/blah/blah: file exists", which they do. In fact /user/fran does not currently exist on the filer (thus the restore), and /user/miller does. My question is: why is the restore touching anything but /user/fran in the first place? Any info on the proper syntax would be greatly appreciated. Regards, /charles Charles Homan System & Network Opertions Group Applix, Inc.

2 2

can't control access over CIFS
by Tom Reingold 19 Jan '99

19 Jan '99

One of my users has a CIFS share on one of my toasters. Her boss wants access to her files. This is legitimate, since she is his secretary. The cifs setup says that cifs uses the unix security model. We have tried adding him to the unix group and making sure the unix permissions allow him to access the directory. This didn't work. Setting the mode to 775 gave him permission, but this shows that the group membership isn't working. As a test, I added myself to the unix group, and I *was* able to access the share. Why me and not him. It gets stranger: I removed myself from the group and I was still able to map the share as a drive. At this point, the mode was 770, so I don't think the unix permissions were providing me this unexpected access. Clearly, there is some cacheing going on, but I don't know where, why, or when. What's the best thing to do in this case. I'm basically a unix-head, so doing this with unix permissions is preferable, but not absolutely necessary. I would prefer not to make an NT group, however. Thanks! Tom

2 1

moving data between filers
by Anthony Fiarito 15 Jan '99

15 Jan '99

Here is the scenario: I have two identically configured F630 filers. Filer A is active and contains about 150 gigs of data (all in one volume). Filer B is brand new and empty. I need to replicate the data from Filer A to Filer B with the minimal amount of downtime for Filer A. I could do a vol copy to move the data, but in the time that it would take to complete, much of the data would have changed and would be out of date. I was thinking of some sort of solution where I could do a vol copy (or something similar) of the data from Filer A to Filer B while Filer A was up and running. Once that was done, I should shut down Filer A and resync the changes that were made to Filer A during the copy to Filer B (thus giving me an exact copy of the data on each netapp). It would be similar to doing a level 0 dump while everything was active, and then a level 1 while they were shut down. The problem though is that I need them to be synched exactly (i.e. files/dirs that get deleted from Filer A during the initial copy would also get deleted from Filer B during the sync phase). Another option might be to do an rdist from Filer A to Filer B of the data while they are active, isolate them from the network once that is done, and re-run rdist to sync of any changes that took place during the initial move. With 150 gigs of data though, this would probably take a ReallyLongTime[tm], thus not being a viable solution. Has anyone tackled a situation like this before? What methods did you use and in what sort of time frame were you able perform the replication? Thanks in advance for any feedback. -alf --- Anthony Fiarito alf(a)cp.net Critical Path Operations

5 4

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