toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

working around lack of NTP
by Daniel Quinlan 10 Oct '98

10 Oct '98

NetApp does not support NTP, so we must set the system time via periodic "rdate" commands. We have found that running rdate too often (or at the wrong time of day) can cause regularly scheduled jobs (such as scrubs) to be missed. Right now, we're setting the time three times a day, but that doesn't cut it. Some programs bitch that time is "going backwards" and other nonsense because the NetApp isn't synchronized with everything else. (*) I'd like to know when NetApp cron jobs (other than scrubs -- I know when they happen) are scheduled, so we can run "rdate" more often, but without causing problems. What I'm trying to do (fix the time problem we're having) is really futile, of course. You can't synchronize crap with rdate. - Dan (*) this is really easy to reproduce, by creating a file and running stat() on it immediately afterwards. This script shows the problem: ------- start of cut text -------------- #!/usr/local/bin/perl require "ctime.pl"; require "stat.pl"; die "usage: $0 [filename]\n" unless $ARGV[0]; open(TEST, "> $ARGV[0]"); close(TEST); do Stat($ARGV[0]); $now = time(); print "atime = ", &ctime($st_atime); print "mtime = ", &ctime($st_mtime); print "ctime = ", &ctime($st_ctime); print "adiff = ", ($now - $st_atime), "\n"; print "mdiff = ", ($now - $st_mtime), "\n"; print "cdiff = ", ($now - $st_ctime), "\n"; ------- end ---------------------------- Run it against a NetApp that is "synchronized": ------- start of cut text -------------- $ ./stat-test foo atime = Fri Oct 9 19:26:11 1998 mtime = Fri Oct 9 19:28:37 1998 ctime = Fri Oct 9 19:28:37 1998 adiff = 145 mdiff = -1 cdiff = -1 ------- end ---------------------------- $now should always be >= than all of the timestamps.

1 0

4.x to 5.x upgrade
by alexei＠cimedia.com 09 Oct '98

09 Oct '98

As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade? Thanks. Alex

6 5

Re: 4.x to 5.x upgrade
by stephen＠netapp.com 09 Oct '98

09 Oct '98

> stephen(a)netapp.com (Stephen Manley) writes: > > > More specifically, in 5.1 (not 5.0) we don't allow tape record sizes > > greater than 64KB and we default to 63KB (rather than 10KB). > Note, that this limitation does not apply to NDMP to locally attached tape, or the NDMP 3-way backup. Sm

1 0

None
by yingchih＠mitac.com.tw 08 Oct '98

08 Oct '98

Unsubscribe toasters

1 0

unsubscribe
by Tim Lewis 08 Oct '98

08 Oct '98

Unsubscribe

1 0

None
by yingchih＠mitac.com.tw 08 Oct '98

08 Oct '98

unscrible toasters

1 0

Re: NetApp and Solaris: setfacl and getfacl
by sirbruce＠ix.netcom.com 07 Oct '98

07 Oct '98

On 10/06/98 17:19:32 you wrote: >I know that Net App filers and Auspexes are more reliable than Sun's >however in practice the difference is minimal. I also know that they >are faster but in practice it isn't so noticeable. We do everything we >can to avoid NFS e.g. cachefs, and most of our users seem to be of the >save and forget variety so we don't really need the performance either. It just goes to show that there are a lot of different environments out there. :) You don't specify exactly what sort of environment you have, but it sounds like it's very low key. You obviously aren't concerned with heavy Internet traffic, multiuser loads, email delivery, database or CAD simulations, etc. Sure, I could see where if you just need a server to store user files, primarily documents and a small amount of email and the like, an ordinary Sun or NT server would be just fine. And since your space needs aren't as great either (generally) in such environments, you probably view disk storage very differently. >Price will probably dictate most which way we go in future and CIFS is >a big incentive but on alternate wednesdays I still favour Sun's. I'm surprised you mentioned price, since the impression I'm getting is that you wouldn't be adverse to paying more for a standard, good ol' Sun that you all know and love. But my previous guess as to your environment may be way off, so what do I know? :) >| In an odd way, since UNIX has generally done without ACLs for so long, >| most places that I know of who could use them don't, since it's not >| really necessary and it's not going to be interoperate well in a >| heterogeneous environment. So I don't know of many customers who would >| decide that they were going to rollout widespread ACL use and switch >| all of their servers over to Sun to accomodate this. > >I would definitely use ACL's if I could but 90% of our file storage is >on machines that don't support them. I also like to use better security, >same story. I'm curious what exactly you would use them for - just intellectual curiosity, mind you, not the argumentative kind. Is security a problem currently? Will ACLs solve a particular problem with sharing files among users you're currently running into? Or do you plan to use it as a basis of a new file-sharing architecture? Do you anticipate any difficulty in getting users to use ACLs, and use them correctly? I haven't seen many UNIX environments heavily use ACLs, so I'm curious as to what people are envisioning. I'm familiar with how they are commonly used on the NT side, but the needs there are different. Bruce

1 0

None
by gordon＠nabaus.com.au 06 Oct '98

06 Oct '98

unsubscribe toasters

1 0

Re: NetApp and Solaris: setfacl and getfacl
by sirbruce＠ix.netcom.com 06 Oct '98

06 Oct '98

On 10/05/98 10:44:36 you wrote: > >+----- On Fri, 02 Oct 1998 20:07:01 CDT, writes: >| The last time the subject of ACLs came up, I sent >| out a message that said the following: >| >| I'd like to see them support all the different ACL types, Solaris, NT, >| Digital Unix, Irix, etc. (at least, I think the latter two have them) >| and have them all interoperate reasonably well. But that's no doubt a >| big undertaking for Netapp with very little return. >| >| It might make more sense is to wait on a standard ACL protocol (maybe >| as part of NFS v4) and then implement that and everyone will talk the >| same language. > >The ACL's are handled with a separate protocol which is IMHO the best >way to handle them. One only needs to look at the SMB^H^H^HCIFS >protocol to see the wisdom of doing it this way. The protocol is even >rudimentally described in /usr/include/rpcsvc/nfs_acl.x. > >| I hve reasons to believe the above statement is still an accurate >| reflection of NTAP's plans. Of course, ACLs for NT were necessary, >| and given the nature of the next NFS standard it may become important >| for them to implement Solaris ACLs as well. It will be interesting >| to see if they can make NT and NFS ACLs interoperate - if anyone can, >| I'm confident it will be Netapp. :) > >In the mean time it's a plus for Sun and a minus for Network Appliance. >After many years of working with Auspex servers I have come to the >conclusion that if you want NFS then Sun is your safest bet, if not >always fastest or best performance. Well, I suppose if you want access to "new" features, such as NFS v3 or ACLs, you're right - Sun tends to have them first before other vendors. However, most places I'm familiar with would rather have better performance and reliability and so on, and if that means not having NFS ACLs, so be it. In an odd way, since UNIX has generally done without ACLs for so long, most places that I know of who could use them don't, since it's not really necessary and it's not going to be interoperate well in a heterogeneous environment. So I don't know of many customers who would decide that they were going to rollout widespread ACL use and switch all of their servers over to Sun to accomodate this. Bruce

2 1

Re: NetApp and Solaris: setfacl and getfacl
by sirbruce＠ix.netcom.com 05 Oct '98

05 Oct '98

The last time the subject of ACLs came up, I sent out a message that said the following: I'd like to see them support all the different ACL types, Solaris, NT, Digital Unix, Irix, etc. (at least, I think the latter two have them) and have them all interoperate reasonably well. But that's no doubt a big undertaking for Netapp with very little return. It might make more sense is to wait on a standard ACL protocol (maybe as part of NFS v4) and then implement that and everyone will talk the same language. I hve reasons to believe the above statement is still an accurate reflection of NTAP's plans. Of course, ACLs for NT were necessary, and given the nature of the next NFS standard it may become important for them to implement Solaris ACLs as well. It will be interesting to see if they can make NT and NFS ACLs interoperate - if anyone can, I'm confident it will be Netapp. :) Bruce

3 2

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