toasters January 1999

toasters@lists.teaparty.net

71 participants
68 discussions

Start a nNew thread

Fwd: Re: duplicate inode numbers - correct URL
by Andrew Bond 25 Jan '99

25 Jan '99

1 0

duplicate inode numbers
by Tom Reingold 25 Jan '99

25 Jan '99

Hey! My user could not copy a snapshot to the original place because "cp" claimed the files are identical. I think cp thinks so because the inode numbers are the same. The files do not have identical contents, so it seems like a serious bug that the filer issued duplicate inode numbers. Am I wrong? The output belog is wide. Please view it with a wide window. # ls -il myfile .snapshot/*/myfile 2436244 -rw-rw---- 1 pete pete 85933 Jan 24 17:50 .snapshot/hourly.0/myfile 2436244 -rw-rw---- 1 pete pete 85211 Jan 24 15:50 .snapshot/hourly.1/myfile 2436244 -rw-rw---- 1 pete pete 84223 Jan 24 11:56 .snapshot/hourly.2/myfile 971294 -rw-rw---- 1 pete pete 83436 Jan 24 00:47 .snapshot/hourly.3/myfile 971294 -rw-rw---- 1 pete pete 79270 Jan 23 12:57 .snapshot/hourly.4/myfile 971294 -rw-rw---- 1 pete pete 79270 Jan 23 12:57 .snapshot/hourly.5/myfile 971294 -rw-rw---- 1 pete pete 75104 Jan 23 02:42 .snapshot/hourly.6/myfile 971294 -rw-rw---- 1 pete pete 75104 Jan 23 02:42 .snapshot/hourly.7/myfile 971294 -rw-rw---- 1 pete pete 79270 Jan 23 12:57 .snapshot/nightly.0/myfile 971294 -rw-rw---- 1 pete pete 70938 Jan 22 19:41 .snapshot/nightly.1/myfile 971294 -rw-rw---- 1 pete pete 62606 Jan 21 22:20 .snapshot/nightly.2/myfile 2436244 -rw-rw---- 1 pete pete 86541 Jan 24 22:24 myfile Tom Reingold tommy(a)bell-labs.com http://www.bell-labs.com/~tommy Bell Labs, the Research and Development unit of Lucent Technologies Murray Hill, NJ, 07974-0636 US

2 1

Microsoft exchange
by Jason Middlebrooks 24 Jan '99

24 Jan '99

Is Microsoft exchange supported on the netapp filers? Jason Middlebrooks Systems Engineer Datalink Phone: 770-933-9327x260 2264 Northwest Parkway, Suite I Pager: 888-502-1625 Marietta, GA 30067 Fax: 770-933-9272

10 11

Recoverable error rates
by Aiello, Tony 24 Jan '99

24 Jan '99

Hello, There's been some questions of late regarding the meaning of soft or recovered errors. A recovered error is defined as the disk needing to take some action other than the initial access to the media in order to satisfy an i/o request. The methods used may be to retry the request, reseeking to the sector, recreating the data from error correction information or all of the above. Recovered errors do not indicate pending disk failure. Drive manufacturer's specify a bit error rate of so many recoverable errors per bits of access. Note that bits of access includes sector overhead. A 512 byte sector is bracketed by header and trailer information used to keep track of the location as well as error recovery information. While recovered errors do not in themselves indicate pending drive failure, an excessive rate of more than 10 a day on a filer under average load would indicate problems in media management. This condition must be examined more closely to really quantify the error rate. A single sector written with a bit flip will always return a recovered event when read. Naturally. The ECC does not match the stored data so the error correction is invoked to reproduce the proper image. So when examining the recovered error log look at the block address. If each entry references the same block, that is ONE recovered error, regardless of how many entries are made against it. If each one indicates a different address then the amount of traffic must be considered. Using sysstat to look at the megabyte per second rating of the system. Using that determine the megabyte per hour rating. Multiply by 8 to get bits. A reasonable number of for the recovered error rate is 10 per 10^12 bits of access. So consider a disk giving an average response of 20 ms per 4K i/o. It's serving 50 transactions per second or .2 MB/sec. In a 24 hour period then it serves about 1.4 * 10^11 bits. Not far from the recovered bit error rate. So a recovered error every day would not even be excessive. Naturally a filer serving more transactions per second would have a higher rate of expected recovered errors. Realistically, disks don't perform that poorly and may go for long periods of time without reporting a single recovery event. Our primary motivation in logging these events is more for performance. Since error recovery takes time, a disk having a large number of recovered errors could adversely effect performance. So we log these as a means to aid in diagnosing performance problems. The short story is: drives are expected to have these recovered errors. Recovered errors don't indicate a pending failure. Removing a disk because of soft errors wastes time and materials. Futher it exposes you to real damage should some other device experience an unrecoverable error. Tony -------------------------- mailto: taiello(a)netapp.com Ph:(408) 367-3251 Fax: (408) 367-3151

3 2

Re: NFS mail spool [ Was Re: Microsoft exchange ]
by Keith Brown 22 Jan '99

22 Jan '99

Use of NetApp filer technology to act as the storage portion of large scale e-mail installations is a relatively common application of our products. Almost "routine" in fact! :-) A very good technical paper has been written by one of our customers on this subject, which can be perused at: http://www.earthlink.com/about/papers/mailarch.html A similar paper describing the net news application of filers is also available from: http://www.earthlink.com/about/papers/scalenews.html A recently published article on the subject of "Hosting E-Mail for Heavyweights", involving our storage solutions can be viewed at: http://www.internetworld.com/print/1998/10/12/infrastructure/19981012-hosti… tml And finally, one of our own papers on the subject of e-mail performance benchmarking is available from: http://www.netapp.com/technology/level3/3022.html All just FYI... Keith

1 0

RE: Microsoft exchange
by Mohler, Jeff 22 Jan '99

22 Jan '99

While we're on the subject of mail, I was thinking of moving our sendmail spool area from a drive local to the Sun mail server to one of our NetApp boxes. Anyone have any pros/cons regarding NFS mounting the mail spool to the mail server? -- Two words. Dot locking. (procmail)

1 0

Re: Microsoft exchange
by Jason D. Kelleher 22 Jan '99

22 Jan '99

In message <199901221550.KAA20198(a)prospero.dma.isg.mot.com>, Gordon Keegan w rites: >> On Fri, Jan 22, 1999 at 09:47:48AM -0500, Jason Middlebrooks wrote: >> > Is Microsoft exchange supported on the netapp filers? >> >> Actually, I think exchange requires that all data be stored on local >> drives, just like SQL server does. >> >> -- > >While we're on the subject of mail, I was thinking of moving our >sendmail spool area from a drive local to the Sun mail server to >one of our NetApp boxes. Anyone have any pros/cons regarding NFS >mounting the mail spool to the mail server? Stale NFS file locks caused us some problems initially (procmail processes would clog the server waiting on locks), but that was bug #6118 which was fixed in 5.x. Other than that, no problems. And it's nice to be able to pull accidentally deleted messages out of snapshots. jason

1 0

Sybase not SQL
by Robert Black 22 Jan '99

22 Jan '99

Opps! Sorry all my brain was thinking SQL my eyes were seen Sybase. Been that kind of week. Bob ----------------------------------------------------------------- Robert Black Email: bobbl(a)netapp.com Network Appliance, Inc. Voice: (800) 550-6827 Systems Engineer - Pacific NW Pager: (800) 465-7149 -----------------------------------------------------------------

1 0

RE: Microsoft exchange
by Allison, Bridget 22 Jan '99

22 Jan '99

> Actually, I think exchange requires that all data be stored on local > drives, just like SQL server does. That's true today but NetApp is working with Microsoft to change that. Check out http://now.netapp.com/solutions/index.shtml (requires NOW login and password) for more info. If you need more info after that then contact me directly at bridget(a)netapp.com Bridget ============================= Bridget Allison Network Appliance Inc. office: (408) 367 3419 cell: (408) 823 1126

1 0

unsubscribe
by Daniel Long 22 Jan '99

22 Jan '99

unsubscribe

1 0

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 January 1999