toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

Re: Y2k test on Filer F720 with OnTap 5.2.2
by Patrick Day 30 Nov '99

30 Nov '99

Hi, we have extensively tested the 5.2.2p1 (which i am sure is as compliant as 5.2.2) on several 740's and found no problems with the date rollover. There is an upper limit around 2037 that the filer can't handle correctly. it has passed all the major date tests such as 2/29/2000, 10/10/2000, 1/1/2001, etc... you shouldn't have any problems with the rollover. --patrick day bayer corp. mathworks owner-toasters <owner-toasters(a)mathworks.com> on 11/30/99 07:45:57 AM To: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 cc: Subject: Y2k test on Filer F720 with OnTap 5.2.2 I plan to change date to December 31th 1999 on our filer F720 with ONTAP 5.2.2 and see whether it is smoothly rollover to Year 2000 or not. Is there anybody have test it? I would like get some experience from you. Thank you in advance!!! Best Regards Amy

1 0

RE: Problems with file dates
by Plawner, Marom 30 Nov '99

30 Nov '99

I don't know if there is any relation at all, but I was having a problem in the CIFS environment. If I used the resource kit's robocopy, when I copied files over, all the times looked right. Robocopy is supposed to copy only newer files; so when I used robocopy again on the same directory, I expected only changed files to update... but the weird thing was that it said some files were OLDER (very odd), some were NEWER (odd since they didn't change), etc. I spoke with a friend of mine who also has a file and experience the same problems. More dependant on robocopy, my friend did some serious investigation and found that the problem was that the filer doesn't work properly if it isn't set to UTC. (We use UTC +5.) He changed the time zone and the problems disappeared. I don't depend on robocopy, so I haven't yet done this. I don't know if it helps, but maybe this is related to the problem. Marom Plawner Systems Group Manager Comverse Network Systems -----Original Message----- From: David H. Brierley [mailto:dhb@ssd.ray.com] Sent: Monday, November 29, 1999 11:25 PM To: Bruce Sterling Woodcock Cc: Dave Atkin; toasters(a)mathworks.com Subject: Re: Problems with file dates On Thu, 25 Nov 1999, Bruce Sterling Woodcock wrote: > Regardless of whether or not the dates are being set due to a bug or > improper setup > with the clients or even with the filer, Solaris should not be choking. The > correct > solution is to get Sun to issue a real working patch, and not to use Solaris > 7 in the > meantime. The problem is not limited to Solaris 7. I encountered the same problem on one of my Solaris 2.5.1 boxes. I was trying to remove an entire directory and it simply refused to remove one particular file. Since it was just one file I just pushed the whole issue aside until I could get back to it later. The next day I tried the remove again and this time it worked but then I realized I was not logged in on the Solaris machine this time but instead I was using on of our older Sunos 4.1.4 machines. -- David H. Brierley Raytheon Systems Company - Portsmouth RI Facility Work: dhb(a)ssd.ray.com Home: dave(a)galaxia.com

1 0

Problems with file dates
by Dave Atkin 29 Nov '99

29 Nov '99

We are finding an increasing number of user files (several thousand files at present) with bizarre dates, eg -rwx--x--x 1 rfx3 ug93 49 Dec 27 1931 /usr/fsa/ug93/rfx3/letter-home -rwx--x--x 1 socx12 socs 460 Jul 22 1948 /usr/fsa/extn/socx12/nov2nd The dates display mainly in the 1930s although there are a few around the year 2009! These files seem to have been created over CIFS from PCs running Windows 95. It becomes a real problem if you run Solaris 7 which seems to have numerous bugs in the area of NFS file dates. It won't read, write or delete these files - it says "Value too large for user buffer". It's all related to 64-bit vs 32-bit Solaris and whether dates are signed or unsigned. SGI systems and older Solaris systems don't have the problem. Having talked to Sun I tried patching the kernel variable nfs_32_time_ok to be 0xffffffff which appears to fix it, except it breaks other things like the utime system call. The best option at present seem to be to run a weekly script on a non-solaris 7 system to find the bad files and "touch" them. Any ideas anyone? ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

4 3

dump formats incompat. between 4.x and 5x. ?
by Dennis Chandler 29 Nov '99

29 Nov '99

I've been trying to load older dump tapes (ontap 4.3.3) to our new filer (ontap 5.2.3) and nothing is working. Solaris ufsrestore complains that the tapes aren't in dump format and attempts to load with filer dump fails miserably. Why wouldn't NetApp make these formats compatible? Dennis

2 1

Roaming profiles on toaster?
by Colm Buckley 29 Nov '99

29 Nov '99

Folks - I'm trying to track down a problem here, and I'm wondering if anyone else in this forum has encountered something like the following: We have a large number of students whose home directories are stored on a NetApp F720 called "swift". Using Windows NT clients, these are generally mapped as the user's home drive at logon (everything's in a Windows NT domain). For example, user "joesmith" might have a home directory set to "\\toaster\joesmith" (mapped to the U: drive at logon). So far so crunchy. However, the users' NT roaming profiles are also stored on the filer - for "joesmith", his profile is at "\\toaster\joesmith\.NTProfile" and so on. Everything seems to work okay 95% of the time, except I have noticed that users' profiles become corrupted with puzzling frequency - more than I can attribute to things like quota overflows or turning the computers off in mid-logout (yes, we get those too). Could it be a problem with the interaction between an NT client and the filer? Does anyone else have a setup similar to this? Noticed any problems? Colm (of course, it could just be more brain-death in NT) -- Colm Buckley B.A. B.F. # colm(a)tuatha.org colm.buckley(a)cs.tcd.ie Department of Computer Science # +353 87 2469146 # whois cb3765 Trinity College, Dublin 2, Ireland. # http://www.tuatha.org/~colm/ If at first you don't succeed, to hell with it.

1 0

Re: User Quotas in CIFS Environment
by Luke Mewburn 28 Nov '99

28 Nov '99

"Plawner, Marom" writes: > One other problem: > (Related but not completely related, so I deleted the original message) > When a user@tree quota is assigned, each user sees the whole volume's disk > space, not their quota limit and their current disk usage. Anyone noticed > this problem or better yet, knows of a solution? I've seen this recently too. However, I was sure that in the past I've seen the filers do the right thing. Maybe something got broken, but like you, I'd expect that the user should see the size of the share as the size of their quota, not the total share size. Or at least have it an option that can be enabled... (We've been using user@tree quotas and CIFS for a couple of years now, and I've seen various bits of behaviour change between releases...)

1 0

RE: User Quotas in CIFS Environment
by Plawner, Marom 28 Nov '99

28 Nov '99

One other problem: (Related but not completely related, so I deleted the original message) When a user@tree quota is assigned, each user sees the whole volume's disk space, not their quota limit and their current disk usage. Anyone noticed this problem or better yet, knows of a solution? Thanks, Marom Plawner ITI Systems Group Manager Comverse Network Systems

1 0

User Quotas in CIFS Environment
by Plawner, Marom 28 Nov '99

28 Nov '99

Hello! We're using the F720 in a pure CIFS environment. We have the: Cifs.home_dir = /users option enabled. Basically, every user automatically gets a home directory on the filer. (Assuming that they have a directory in the /users folder in their username... we have a login script that creates this if they don't, and maps it to a drive letter.) In the quotas, we have a line: * user@/vol/vol0/users 250M # Default users get 250MB home dir Supposedly, each CIFS user who connects is supposed to get 250 MB quota. But what happened is that all users had just a total of 250 MB COMBINED! Why? Because all users were mapped to 1 account name, and that account got 250 MB quota. To work around this problem, we have to import all users from the NT domain to the /etc/passwd file. Not passwords or anything, just use the migrate program. This solves the problem, but creates new problems: * The command line version of the migration tool doesn't work on our domain (of about 4,000 users). I tried in all sorts of configurations, it crashes every time. * The Beta version of the GUI Migration tool works nicely, but I have to run it by hand (no command line parameters as far as I know) * Our company grows about 100 new employees a month, this must be done all the time * If the UID of an account in the /etc/passwd file gets changed, it starts the quota from 0 (even if the directory was full). Therefore, it is very important the whoever runs the program does it right! I don't have the time to do it, but I don't trust anyone else to not screw everything up! Possible solutions: * I thought: maybe an NIS server running on NT reading the SAM database could update the /etc/passwd file automatically. * Some knows of some hidden command line features of the GUI migration tool * Someone at Netapp could provide some sort of support and fix the dos based tool or make something work properly. (Sorry, but I've been sending this question to Netapp and our local suppliers for about 11 months now and I'm fed up with the lack of response I'm getting) * Someone could explain if this wafl.default_nt_user is in any way connected * Maybe someone knows something more (reason for writing). Help would be much appreciated. Thanks! Marom Plawner ITI Systems Group Manager Comverse Network Systems

1 0

rdate
by Priebe, Jason 26 Nov '99

26 Nov '99

Anybody else had trouble getting rdate to work properly on a filer? I'm trying to get rdate on my F720 to contact a Linux server to get the time, and it comes back with the message "rdate: no response from <myhostnamehere>" The Linux box is definitely listening for connections on port 37, and it seems to be responding fine when other boxes make requests to it. I'm pretty sure it's not related to the F720's network configuration. I wish I could test it against other time servers, but it lives on a private network. Jason Priebe WRAL OnLine http://www.wral-tv.com/

4 3

Misc equipment
by Crve＠aol.com 25 Nov '99

25 Nov '99

Anyone out there looking for the following Extreme Network Summit1 Seagate ST 19171FC Fiber Channel Drives (102 available) Xyplex 9000 Cisco Cards AS5300 As5200 AS5800 Newbridge router and Switches Sun ATL Libaries 1800 3500 new us4d only for evauation by sun! Craig Crve(a)aol.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