toasters June 1998

toasters@lists.teaparty.net

36 participants
44 discussions

Y2K Testing & compliance
by Thomson, Michael 25 Sep '98

25 Sep '98

Hi there! I've been asked some questions by our Y2K project team, specifically related to NetApp, and I'm unsure how to respond. >From the web page (http://www.netapp.com/y2k_table.html) it seems that the only thing that is 'preliminarily evaluated' is DOT 4.1. Can anyone give the authorative answer to: 1) Are there any plans to use a hardware clock that stores 4-digit years? 2) What Y2K tests were performed on DOT 4.1 3) Have later releases (4.1.3, 5.0, etc.) had the same tests run on them before release? 4) Can customers get access to NetApp test plans and results, directly or via a non-disclosure agreement? More generally, are people inclined to believe that, once certified by NetApp, the appliances can be treated as 'any other' NFS server by client machines, or would you advocate specific interoperational testing with NetApp kit? Cheers, Mike Thomson -- \\|||// Minds are like parachutes; (@ @) They only work when open. *---oOO-(_)-OOo------------------------------------* * Michael Thomson Email: mt53590(a)ggr.co.uk * * Unix Specialist Internal: 782 4393 * * Glaxo Wellcome External: 01438 764 393 * * Fax: 01438 763 204 * * .oooO Oooo. Mobile: 0498 725 047 * *--( )---( )-----------------------------------* \ ( ) / (Quote: Sir James Dewar) \_) (_/

4 6

Re: Support for Network Time Protocol?
by Daniel Quinlan 04 Sep '98

04 Sep '98

Daniel Quinlan <quinlan(a)transmeta.com> writes: > I'm also interesting in NTP support, but I think I'd like to see the > current software become a lot more reliable (and complete) before > adding another new feature. All I need is more NetApp crashes because > of NTP bugs. I should add that this happened to us just a few days ago: - xntpd died on our adminhost (that ran the cron job to set the NetApp dates) - time drifted by 8 minutes on the adminhost and the filers over the course over a few days - someone started having problems, managed to figure out that it was because of the time drift, and we fixed it. (Other people probably had problems, but didn't report them.) To prevent it from happening again, we're remotely monitoring the system time of the adminhost (using "mon") to make sure it doesn't drift off again. Incidentally, there seems to be no way to remotely query the system time from a NetApp (except by creating a new file and running stat() on it, or by using unsupported/hidden commands). However, I'm still saying that I don't want NTP until other supported protocols (such as NDMP) start working reliably. Dan

1 1

posting history - who's wordy and who's quiet?
by Tom Yates 08 Jul '98

08 Jul '98

i was looking for a reason to have fun with perl modules for chopping up email addresses, so here's the prolixity summary for the lifetime of the list. i've cut-off at ten posts. 99 Brian Tao 86 sirbruce(a)ix.netcom.com 55 Alexei Rodriguez 49 Daniel Quinlan 47 Tom Yates 45 Dave Hitz 37 Guy Harris 30 Jaye Mathisen 30 David Drum 25 Kenneth Whittaker 23 sthaug(a)nethelp.no 22 Chris Caputo 21 Marc Nicholas 19 alexei(a)cimedia.com 19 Karl Swartz 18 Jonah Yokubaitis 16 Weeks, Thomas 16 Matthew Zeier 16 Bruce Sterling Woodcock 16 Amy Chused 15 Jim Davis 15 Christoph Doerbeck 14 Mark D Simmons 14 Dave Cole 13 rasmus(a)bellglobal.com 13 Simmons Mr M D 12 Rasmus Lerdorf 12 Ragnar Lonn 12 Brian Pawlowski 11 Steve Gremban 11 Keith Brown 11 Jason D Kelleher 10 Philip Thomas 10 Ketil Kirkerud 10 Dave Pascoe Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

5 4

'quota resize' - any way around it ?
by James FitzGibbon 08 Jul '98

08 Jul '98

Is there *any* way (and I'm open to any suggestions) to get around the inability of 'quota resize' to handle additions/deletions from the /etc/quotas file ? The problem I'm stuck with is trying to provide realtime addition of users (with quotas) on a 100GB filer without having to turn quotas off and on, which is currently a 26 minute process. During these 26 minues, no quotas are enforced. Acceptable once a night, but not as often as they want me to run it. A few of ideas (in order of ascending lunacy): - just accept the fact that NetApp doesn't consider this wish to very important and turn the quotas on/off as often as is feasible. - set a default quota for the export, and just create a new quotas file once per night. - preload the /etc/quotas file with entries for all possible UIDs, then just change the quota as they request it. This way the /etc/quotas will always be the same length and contain the same number of users. - get NetApp to allow an SNMP SET request to implement this functionality - try to figure out the format of /etc/db/quota.db and manipulate it directly. - kidnap Dave Hitz (presuming he's still there) and have him add the feature at gunpoint. - Quit. TIA. -- j. James FitzGibbon james(a)ican.net System Engineer, ACC Global Net Voice/Fax (416)207-7171/7610

4 4

Re: what data is being used?
by Mark D Simmons 29 Jun '98

29 Jun '98

I recall asking for this in an RFE sense a year ago as it would be incredibly useful. Sun just put the capability to track the load on disks at the partition level in Solaris 2.6 - this sort of stat on a filer would be just as useful IMHO Per quota tree seemed most natural to me as that is already a distinctive structure in filer housekeeping meta-data. Directory level gathering might be too much load to put on a filer which is meant to perform under high demand... ...how about an admin command that flips a bit on a directory and makes it a watchpoint in the filesystem - accesses against anything beneath it count on that directory's stats. Even if the total number of such points were limited to put a boundary on overhead in the filer, it would still be a useful analytical tool.

1 0

Zowie! He's using 4 TB!
by Brian Rice 26 Jun '98

26 Jun '98

Has anyone else seen this little sparkle in the output of quota report? user sairam 4294947972 5120000 4294967282 512000 This shows up intermittently after I move a user to the filer with a restore rfD - . As you might imagine, it prevents the user from writing. Workaround is quota off; quota on. This is on an F630 running 4.3.3. I haven't filed a bug report yet, though I will as soon as I have confidence that I can state the sequence of events that triggers this phenomenon. Just curious to see if anyone else had seen it. Brian Rice brice(a)gnac.com

2 1

what data is being used?
by Daniel Quinlan 26 Jun '98

26 Jun '98

Are there any tools to gauge NFS load (reads, writes, NFS ops, whatever), perhaps on a quota tree or directory level. Why would I want to know such a thing? Say I have an 200GB F540 filer with two large trees. And I just purchased a 200GB F630 filer. I want to move one of the trees, but not both. I want to move the busier one, not the other one. There are some basic things I've been looking at in the above situation, but maybe someone here knows about a better method/technique/tool. I hoping someone will mention such an obvious solution that I'll be glad I didn't mention what sort of thing I've been doing. :-) - Dan

1 0

Re: Making CIFS hidden files from unix
by Daniel Quinlan 26 Jun '98

26 Jun '98

Steve Losen <scl(a)sasha.acc.virginia.edu> writes: > When we add new user accounts to our NetApp, we don't know if the owner > will use CIFS, unix, or both. (We use unix file protection semantics.) So > we are going to put unix dot files in the new home directory. But it > would be nice to prevent or discourage CIFS users from deleting them -- in > particular the .forward file. We were thinking that if we could make the > dot files "hidden" and "system", that that would help, even though CIFS > users can override and see hidden files if they want. > > [...] > > Is this overly complex? Is there a simpler way? Yes. I think so. A simpler solution is to configure sendmail to look for .forward files somewhere other than home directories. We put all .forward files (as well as procmail stuff) in a centralized location (physically on the mail server). For example, /local/mail/<username>/.forward /local/mail can be (auto)mounted to allow editing on clients. You can put symbolic links in user home directories, and it won't matter if people delete the links. This also allows for faster and more reliable mail delivery since the .forward files are now located on the mail server. You don't need to worry about someone's home directory being unavailable. - Dan

1 0

Making CIFS hidden files from unix
by Steve Losen 25 Jun '98

25 Jun '98

When we add new user accounts to our NetApp, we don't know if the owner will use CIFS, unix, or both. (We use unix file protection semantics.) So we are going to put unix dot files in the new home directory. But it would be nice to prevent or discourage CIFS users from deleting them -- in particular the .forward file. We were thinking that if we could make the dot files "hidden" and "system", that that would help, even though CIFS users can override and see hidden files if they want. Our account adding software is on unix, and I think I have a way to do what I want. I'll make a "new user" prototype directory and set the unix permissions on the dot files, then get on a PC and set "hidden" and "system" on them. I'll use the netapp dump utility to dump the prototype dir to a file. When I create a user, I'll use the netapp restore to bring back the prototype directory, chown the files to the new user, overwrite the .forward, and mv the prototype into place as the user's home dir. This preserves any CIFS hidden attributes, I presume. It looks like restore always restores back to the original location of the dumped directory. Is it possible to get restore to restore elsewhere? We're running NetApp Release 4.3.1. Is this overly complex? Is there a simpler way? Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

Re: always safe to delete dump snapshots?
by Paul Albers 25 Jun '98

25 Jun '98

Dan and Bruce, This was bug #650 and has been fixed in all the OnTap OS releases since 4.3x. The request to delete this snapshot_for_dump.<num> will fail. -paul At 08:42 AM 6/25/98 -0500, you wrote: >On 06/25/98 01:38:27 you wrote: >> >>Is it always safe to attempt to delete a snapshot_for_dump.<num>? >> >>Another way to phrase my question -- it will *never* succeed when a >>dump is in progress, right? >> >>Yes, I know it's supposed to not succeed, but since I'm writing a >>program to automatically delete snapshots, I'm exercising more >>paranoia than usual. > >Well, there USED to be an old bug that's been around since the >beginning that trying to delete one while a dump was in progress >would crash the filer. This bug was even mentioned in bold >letters in the admin guide (either in the snapshot or the dump >sections). Assuming they've fixed it to do what you say, then >you're correct. > >If they haven't, then you don't want to automatically delete those >files, unless you have some way of knowing ahead of time that they >are no longer associated with a dump process (say, one that failed >in some ungraceful way). Since this usually happened because of a >crash, one thing I used to do was include an automatic snap delete >at the end of the rc file to delete the snapshot_for_dump after the >filer had started up. The appearance of the snapshot_for_dump.n >mechanism broke that... I made the suggestion that having the OS >automatically delete those might be a good idea, but on the other >hand it might not... the user may really want to restart the >backup off that old image, rather than taking a new one right at >that moment. > >Bruce > > >

1 0

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 June 1998