toasters June 1999

toasters@lists.teaparty.net

85 participants
118 discussions

administrivia
by fubar＠mathworks.com 29 Jun '99

29 Jun '99

FYI, posts made to the list between Sunday evening and just now (10am EDT) will not be appearing in the toasters archive. I seem to recall there being a few posts, but not many. This past weekend was spent moving our servers to our new office building. In the move a few changes were made, and a few things broken. :-) K.

1 0

Re: Disk Controller Failures
by sirbruce＠ix.netcom.com 27 Jun '99

27 Jun '99

On 06/25/99 12:50:17 you wrote: > >Hi there, > > We recently encountered a disk controller failure on one of our >data servers (not on our Netapp). The problem was that this failure was >not a complete failure of the drive itself, but rather the controller >started to >die slowly. (i.e. handles some request sometimes and other times who >knows?) >As a result, this caused our entire filesystem to become corrupt and we lost >some >of our data as a result. Although this filesystem was mirrored, this did >not help us >at all, as it was considered a logical error in the filesystem and not a >hardware problem. > > My question is that should this occur on a Netapps (this may even >apply to >any other Enterprise server) would it cause the entire filesystem to go >corrupt and >cause partial or complete data loss as in this case? I would have to say yes, it's *possible*, but the controller would have to fail in a very odd way; not simply not responding the some requests (that would be caught), but executing some and not others (but claiming it did) or misordering commands or something like that. I would think this kind of error would be very rare. Perhaps the controller you had is particularly prone to those sorts of errors; one advantage of Netapp is you're using controllers they themselves have partially designed and tested. Bruce

2 1

Re: Increasing "maxfiles" and its effect on performance
by sirbruce＠ix.netcom.com 26 Jun '99

26 Jun '99

On 06/25/99 16:40:20 you wrote: > >What affect will increasing the "maxfiles" have on the read/write >performance on a volume? We are currently running Data Ontap ver 5.2.2P1 on >a F740. Very little, unless you set it to an extremely high value that is far, far more than you need. (Like, I dunno, 1 billion?) Even then I doubt it would be very noticeable unless the filer were heavily loaded. If you are running out of files on the filer (which is not unusual if the default setting was conservative and you've added a lot of space), you shouldn't think twice about upping the maxfiles value. I would guess (one of the Netapp WAFL experts could correct me on this) that since maxfiles reserves some space in the filesystem for metdata, that slowly increasing maxfiles over time (rather than in large increases at once) might "fragment" the metadata file across the filesystem, thus hurting performance somewhat. But then I seem to recall that even when you increase maxfiles, this space is not necessarily allocated right away, so maybe it doesn't matter and they'll only grow in a fragmentary fashion anyway. (Fragmentation is not really much of a problem on Netapp's anyway and is only really noticeable on very large files.) Bruce

1 0

Increasing "maxfiles" and its effect on performance
by Mike Ball 25 Jun '99

25 Jun '99

What affect will increasing the "maxfiles" have on the read/write performance on a volume? We are currently running Data Ontap ver 5.2.2P1 on a F740.

1 0

Disk Controller Failures
by Mingway Huang 25 Jun '99

25 Jun '99

Hi there, We recently encountered a disk controller failure on one of our data servers (not on our Netapp). The problem was that this failure was not a complete failure of the drive itself, but rather the controller started to die slowly. (i.e. handles some request sometimes and other times who knows?) As a result, this caused our entire filesystem to become corrupt and we lost some of our data as a result. Although this filesystem was mirrored, this did not help us at all, as it was considered a logical error in the filesystem and not a hardware problem. My question is that should this occur on a Netapps (this may even apply to any other Enterprise server) would it cause the entire filesystem to go corrupt and cause partial or complete data loss as in this case? Mingway Huang Nortel Networks

1 0

RE: list of file lock types
by Hawley, Rob 23 Jun '99

23 Jun '99

CIFS locks have two parts; basically "What I want to Do" and "What I am going to prevent others from doing". "What I want to Do" EXEC == read + execute R&W == read + write Read read Write write "What I am going to prevent others from doing". DenyAll exclusive access to file DenyR others cannot read the file, but can write DenyW others cannot write file, but can read DenyN others can read or write the file DOS special compatibility mode for DOS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > mailto: hawleyr(a)netapp.com <mailto:hawleyr@netapp.com> US Mail: Network Appliance Inc. > Phone: 408-822-6661 2770 San Tomas Expressway > FAX: 408-822-4521 Santa Clara, CA 95051 -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Tuesday, June 22, 1999 2:24 PM To: toasters(a)mathworks.com Subject: list of file lock types When you do a 'cifs sessions host/user', you get a list like: users shares/files opened machine (user) share Exec-denyW \path R&W-denyAll \path Read-denyAll \path Read-denyN \path Read-denyW \path Write-denyN \path Write-denyW \path Where can I find a comprehensive list of these locks, and what they mean? Most are self-explanatory; but, for instance, what is "N" stand for? NetApp Release 5.2.1P2: Tue Mar 16 10:41:03 PST 1999 Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

2 1

RE: quick question about dumping snapshots
by Melvin, Grant 23 Jun '99

23 Jun '99

Hi Jason, > Hmmm... It seems to be _another_ NDMP bug. The first example I > sent out was generated by running the dump from BudTool via NDMP. This is a bug and its been filed as 15998, the following description will be online tomorrow: TITLE: ndmpd updates the dumpdates table incorrectly when dumping pre-existing snapshots DESCRIPTION: In 5.3, if a dump of a pre-existing snapshot (such as /vol/vol0/.snapshot/hourly.0) is used, the dumpdates table is updated without the ".snapshot/hourly.0". It should only show: /vol/vol0/ 0 Sun Jan 1 00:00:00 1999 However, ndmpd prints out /vol/vol0/.snapshot/hourly.0 0 Sun Jan 1 00:00:00 1999 to the dumpdates table and doesn't modify the dump name to "/vol/vol0/". Sorry for the inconvenience. Cheers, Grant

1 0

help on quotas
by Jason Middlebrooks 23 Jun '99

23 Jun '99

I have the following happening. Overview: F630 running OnTap 5.2.2 using CIFS. Two volumnes vol0 and usr. The volume usr contains everybody home directories using cifs.home_dir. I am using a PDC for authentication and I am not using the passwd or group files on the filer. Whats Happening: I have a quota file with the following entries: /vol/usr/usrhomes/cnievesad user@/vol/usr 5G 20K * user@/vol/usr 80M 15K # Default home directory quota /vol/vol0/trafficker tree 5G 15K /vol/vol0/prod tree 2GB 15K /vol/vol0/tsa tree 4GB 50K I have created a new user called msmith and I created the following directory /vol/usr/userhomes/msmith. msmith can map to his directory fine but when I try to create a new folder or file I get the following messages on the filer: Wed Jun 23 14:34:06 GMT [wafl_lopri]: uid 65534: disk quota exceeded on volume usr. The default home directory quota has working in the past at least when I was at OnTap 5.0 Any ideas??? Thanks in advance Jason

1 0

RE: help on quotas
by Benn, Paul 23 Jun '99

23 Jun '99

For quotas to work properly, you will need to setup and maintain an /etc/passwd and an /etc/group file. We're working on a better document specific to quotas but you can have a quick look at section 5.2 in the following document: http://www.netapp.com/technology/level3/3053.html#Sect5.2 Since quotas are based the UID and since you appear to have a CIFS-only filer, each file's UNIX owner needs to be changed to reflect the correct user name instead of "pcuser." I should have a work-around (the document referenced above) posted on the now site in the next week or so. This should be enough info to get it up and running so you can play around with quotas. Best regards, Paul -----Original Message----- From: Jason Middlebrooks [mailto:Jason_Middlebrooks@datalink.com] Sent: Wednesday, June 23, 1999 9:07 AM To: toasters(a)mathworks.com Subject: help on quotas I have the following happening. Overview: F630 running OnTap 5.2.2 using CIFS. Two volumnes vol0 and usr. The volume usr contains everybody home directories using cifs.home_dir. I am using a PDC for authentication and I am not using the passwd or group files on the filer. Whats Happening: I have a quota file with the following entries: /vol/usr/usrhomes/cnievesad user@/vol/usr 5G 20K * user@/vol/usr 80M 15K # Default home directory quota /vol/vol0/trafficker tree 5G 15K /vol/vol0/prod tree 2GB 15K /vol/vol0/tsa tree 4GB 50K I have created a new user called msmith and I created the following directory /vol/usr/userhomes/msmith. msmith can map to his directory fine but when I try to create a new folder or file I get the following messages on the filer: Wed Jun 23 14:34:06 GMT [wafl_lopri]: uid 65534: disk quota exceeded on volume usr. The default home directory quota has working in the past at least when I was at OnTap 5.0 Any ideas??? Thanks in advance Jason

1 0

quick question about dumping snapshots
by Jason D. Kelleher 23 Jun '99

23 Jun '99

According to NOW, backing up from a snapshot should place the "real" path in /etc/dumpdates: NOW: Knowledge Base: Data ONTAP: Backup and Recovery: Backing up the Filer to Tape: FAQ_575 Q: How do I dump an already-created snapshot? A: Essentially, you only need to specify the snapshot in the dump path. For example, to dump the hourly.0 snapshot, run: dump 0uf rst0a /vol/vol0/.snapshot/hourly.0/rest_of_path In pre-Data ONTAP 5.1 releases, the /etc/dumpdates table entry will look like: /vol/vol0/.snapshot/hourly.0/rest_of_path 0 Tue Jul 28 20:39:46 1998 In post-5.1 releases, the /etc/dumpdates table entry will look like: /vol/vol0/rest_of_path 0 Tue Jul 28 20:39:46 1998 Note that if you are running a pre-multi-volume release (pre-5.0, in other words), the command will look like: dump 0uf rst0a /.snapshot/hourly.0/rest_of_path I'm running DOT 5.3D9. So am I doing something wrong, or is this just another example of bad documentation from NetApp? blacklodge: ~ [635] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 blacklodge: ~ [636] # blacklodge: ~ [636] # blacklodge: ~ [636] # grep test /net/bonnie/vol/fs0/etc/dumpdates /vol/fs0/home/test 1 Mon Jun 21 23:49:09 1999 /vol/fs0/home/test 0 Sat Jun 19 01:29:01 1999 /vol/fs0/.snapshot/hourly.0/home/test 0 Tue Jun 22 08:00:54 1999 blacklodge: ~ [637] #

2 2

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 1999