toasters

toasters@lists.teaparty.net

13513 discussions

RE: file system size limit
by Hunter, Peter 14 Oct '98

14 Oct '98

And being new what backup device are you going to use ? Another toaster! ;-) > Is the maximum size of a file system going to change in ONTAP? > > It was my understanding that the max size was limited by a few > factors, > among them the speed of disk reconstruction (max window of opportunity > for duoble failure), the number of physical disks (in a scsi config) > and something else. > > With the advent of multiple raid groups and larger disk sizes, it > seems like > this might be the obvious progression. Lets say that the next drive > size is 18GB. > That means that in a 740 I could have 800GB* per loop. That would > rock. (800GB when > you have 4 raid groups with 12 (11+parity) disks + spares + shared > disk for cluster) > > 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?)). > > I don't need a 1.5TB filesystem.... yet. But it sure would be nice to > be able > to build one :) > > Yes, the more we get the more we want. > > > Thanks. > > > > Alexei >

2 1

Re: Filers and CAP
by Keith Brown 14 Oct '98

14 Oct '98

>Has anyone succesfully configured CAP (columbia Appletalk >Protocol) to work with an NFS mounted filer? Yes. We have at least one other customer that I'm aware of doing this (NFS mounting a filer file system on a UNIX machine, and then running one of the freeware AppleShare/Talk servers on said UNIX machine to "re-export" that file system to Macintosh clients via the Apple protocols). >I am having problems that appear to revolve around NFS file >locking. >[...] >In some circumstances, CAP AUFS using NFS mounted filesystems may complain >about files being locked when they are not obviously so. This is usually >the result of missing lock daemons or simply brain-dead or buggy NFS code. And they don't define exactly *what* circumstances? Hmmm... :-) Well, there's one thing I can think of that may be catching you/it unawares. If you have Windows/CIFS clients concurrently accessing the data that is being accessed by the Macs via NFS (indirectly), the semantic meaning of any CIFS file/record locks that are being established by your Windows clients are enforced on the NFS side in a mandatory way. The various Windows operating systems from Microsoft implement a mandatory locking scheme, and our SecureShare technology ensure that these mandatory controls are honored in the multiprotocol context. That's something to be aware of. What it means in reality is that when/if CAP "probes" for the presence of locks via fcntl(), it may find locks that have originally come from the CIFS side. Also, if it tries to read and/or write data in a manner that would be in violation of a pre-existing CIFS mandatory lock, it will have those operations failed, even though the attempt is being made via NFS. Keith

1 0

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

14 Oct '98

>How far can the fcal cable be and what sort of performace hit >do you take on that 3rd loop (since each loop can only consist of >8 shelves)? As far as performance goes, the three FCAL loops are peers in the system. They are "parallel". Each loop is independently connected into the system via its own FCAL adapter/controller and there is no significant prioritization of requests/responses on any one loop over another. >You figure, the last shelf in the 3rd loop is going to be more than a >few meters away from the filer... Well yes, but distance-from-the-controller is not a significant influencer of device performance on an FCAL loop. This type of fibre channel incorporates some cunning stunts at the MAC layer, borrowed from Token Ring and FDDI, that do an effective job of spreading the available bandwidth betwixt all of the connected players, regardless of their physical position on the loop. Keith

2 1

fcal and the 760
by alexei＠cimedia.com 14 Oct '98

14 Oct '98

Supposedly the 760 can have up to 24 fcal shelves. Now, that is a whole lot of disk shelves (3 racks worth, give or take). How far can the fcal cable be and what sort of performace hit do you take on that 3rd loop (since each loop can only consist of 8 shelves)? You figure, the last shelf in the 3rd loop is going to be more than a few meters away from the filer... Does that make sense? Alex

1 0

Re: Logging CIFS logins
by sirbruce＠ix.netcom.com 14 Oct '98

14 Oct '98

On 10/13/98 15:09:38 you wrote: >If "cifs sessions" can print the active CIFS sessions, then how difficult >could it possibly be to log when these sessions begin and end? No more difficult that logging each NFS mount or unmount, or PC-NFS authentication. >I'm picking on CIFS because each user has an individual session, with an >identifiable beginning and end. Not exactly, as has been identified. Furthermore, you can access a "Microsoft Network" without establishing any session with the filer. You claimed you wanted this not for security, but for knowing if an account is active or not... if I log in, but never access the filer, then you don't have a very good indicator. >NFS works totally differently, but we can >at least get the info we need from unix logs. No. As I pointed out, I could access it via PC-NFS, or straight NFS unless you restrict every host. Furthermore, under unix, I could be accessing other people's files - you might not care about this, but I was just pointing out there's another scenario. >A lot of our students have >their own PCs in their dorm rooms, so we have no access to these PCs. NT >security is not an option for use because we have almost 20,000 accounts >now and will eventually have almost 30,000. I haven't calculated what the >license fee is for 30,000 users on a NT server. At this point, I might suggest that support PCs in dorm rooms isn't an option, unless they use PC-NFS. But that's just me. I view the mapping of CIFS access the UNIX ids and files like the filer does to be something of a hack (not the code, but the concept) - I mean, if you don't like the way Microsoft expects you to use CIFS, don't use it. :) >We are using the same NIS >maps for our unix servers as for CIFS logins on the netapp. It's real >handy for account administration and users have the same password (and >same home directory) for both services. I agree here, but I more universal directory service appears to be in order. LDAP anyone? Bruce

1 0

Re: Logging CIFS logins
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 11:11:44 you wrote: >In our environment, any logging that netapp can provide is probably useful >to us in some way or another. For CIFS, the timestamp, loginid, and >hostname or IP address of the login would be invaluable. All of your resonings are fine, but as I pointed out, you don't really have this information for NFS access either, except to the extent that a UNIX server records a login (but wouldn't if from a PC). So I don't think you should be picking on CIFS on the filer! As I said, running NT security with a PDC would track this information for you. However, having the filer log CIFS and PC-NFS authentications would be useful. Bruce

4 3

Gigabit and Extreme Networks
by Roderic Taft 13 Oct '98

13 Oct '98

I understand that 1000Base-SX is fairly interoperable between vendors these days, but does anybody have any real world experience with a NetApp and an Extreme Networks Summit switch connected with Gigabit? Thanks Rod Taft

3 2

Re: 4.x to 5.x upgrade
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 21:53:10 you wrote: >I produced some interesting phrases the first time my manual changes >to cifsconfig.txt were lost after a reboot. Well, at least said person won't do it twice. :) I know that I pointed out at some point that behavior should be documented, and I believe it was. Assuming it was, and you didn't read the documentation, then you have a conflict of cultures - one person will assume it behaves one way by default and another will assume the other. Whichever is chosen isn't nearly as important as documenting the behavior and making sure people read the documentation! Bruce

1 0

RE: (small?) feature request
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 15:47:32 you wrote: >For commands that can be done via rsh from the admin server, you only need to >use >a shell like bash or tcsh. I'm sure you know that, I only mention it because I >have a related question: > > What is the reasoning behind which commands will work via rsh and which > won't? They are made rsh-able "as needed", because since the filer uses all the same memory space, making a piece of code rsh-safe requires extra effort (think multiple simultaneous executions). Virtually every release, we see a few more commands made rsh-able, but it seems other new features are always more important than cleaning up old code. Bruce

1 0

RE: 4.x to 5.x upgrade
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 11:53:19 you wrote: >A question. Given the choice between: > > - Having a command tell you "there's a conflicting > command already in /etc/rc, you should change it there as well > (or just remove it)" >vs. > - Having the command automatically update /etc/rc with the change, > if it contains a conflicting command. > >Which do you think would be a better approach? The former. I do not trust the software to automatically place the new command in the right place in the /etc/rc file - I've very particular about the order. If there is an automatic change to the /etc/rc file, I want an option to turn it off! :) Bruce

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