toasters March 2006

toasters@lists.teaparty.net

156 participants
215 discussions

yo
by Fredrick S. Macias 12 Mar '06

12 Mar '06

Hello, No Embarrassing Doc_tors Visits. Easier and faster than ever to get the Pres_cr!pt!0ns you need. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ copy the address below and paste in u your web browser: balky.candyball.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In order that the race might live and grow. . While in the wild wood I did lie,. I'll bear it better now --. A novel is cruelly spatchcocked on the bedside table.. For I will be with you till no white brother . Regards, Cody Puckett

1 0

Morning
by neel 12 Mar '06

12 Mar '06

I apologize i've been gone but I just got ur message. I'm not sure how to inform you this but since you're not satisfied with ur lively hood, you may visit here, www.seepointforpeople.com/i3/. It's sad but true, I had to use them too. had meant, that the life which was not rich with self exploration and . t all of us - but a vast majority definitely do. Where we differ - is the degree. Life is not black and white, but grey, all sh. been expelled from Pency, he concludes that his parents would not know of this for a few days. . yure

1 0

RE: "D" CP types on FAS3020
by Glenn Walker 12 Mar '06

12 Mar '06

If I recall, it is more common to see them on filers with smaller memory sizes (ie, 3020\270) than ones with larger memory sizes (960\980). The 'D' CPs are new in 7.X (I don't remember exactly when it was introduced). Are you seeing any issues, by chance, or just hunting for problems to proactively fix? Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Alan Sparks Sent: Saturday, March 11, 2006 11:35 PM To: Toasters List Subject: "D" CP types on FAS3020 Not been getting a clear answer from Support on this, maybe someone here has some good advice or insight... Our FAS3020C filers often display CP types of "D" in a sysstat listing. I get that this is a CP due to "log datavecs." Trying to understand if this is a resource problem, or at least indicative of a performance issue: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 17% 1166 12787 488 793 15683 0 0 >60 100% 55% D 12% 17% 937 13021 454 720 14376 0 0 >60 100% 49% D 10% 18% 1321 13167 538 697 14219 0 0 >60 100% 49% D 10% One thing I got from Support is that it might be indicative of bug 145410 (must actively reclaim resources). At their suggestion, I've updated to DOT 7.0.3 (update from 7.0.2), but still see them a lot of the time. Is this pretty normal for the FAS3000 series? Thanks in advance. -- Alan Sparks, UNIX/Linux Systems Integration and Administration <asparks(a)doublesparks.net>

2 1

getting to know you
by Louella 12 Mar '06

12 Mar '06

Hire, i am here sitting in the internet caffe. Found your email and decided !to write. I might bae coming to your place in 14 days, so I decided to email you. May be we can meet? I am 25 y.o. girl. I have a picture if you want. No need to reply here as ! this is not my email. Write me at mcduw(a)lookyouniceboy.info

1 0

None
by arnouxjj＠free.fr 12 Mar '06

12 Mar '06

Message-Id: <7.0.1.0.2.20060312064321.01e8f418(a)free.fr> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 12 Mar 2006 06:50:16 +0100 To: Alan Sparks <asparks(a)doublesparks.net>, Toasters List <toasters(a)mathworks.com> From: Jean-Jacques ARNOUX <arnouxjj(a)free.fr> Subject: Re: "D" CP types on FAS3020 In-Reply-To: <4413A4EC.50905(a)doublesparks.net> References: <4413A4EC.50905(a)doublesparks.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1004222343==.ALT" --=====================_1004222343==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Alan, i meen that you reach this bug. I have the same on one of my customer site. And i have a huge number of this message. Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.index Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.value Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.next Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.index Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.value Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.next Sun Mar 12 00:00:00 CET [stk-hfm1: kern.uptime.filer:info]: 12:00am up 87 days, 7:48 1447100364 NFS ops, 7295964634 CIFS ops, 4291 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops on others systems i have these messages before upgrading to 7.0.3 or 7.1 as you see on one other system nothing Sat Mar 11 20:00:00 CET [grizzly: kern.uptime.filer:info]: 8:00pm up 49 days, 55 mins, 21659709149 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 21:00:00 CET [grizzly: kern.uptime.filer:info]: 9:00pm up 49 days, 1:55 21697185323 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 22:00:00 CET [grizzly: kern.uptime.filer:info]: 10:00pm up 49 days, 2:55 21732428903 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 23:00:00 CET [grizzly: kern.uptime.filer:info]: 11:00pm up 49 days, 3:55 21761084021 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sun Mar 12 00:00:00 CET [grizzly: kern.uptime.filer:info]: 12:00am up 49 days, 4:55 21782379473 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops but i have no performance issues on both sites. Regards At 05:34 12/03/2006, Alan Sparks wrote: >Not been getting a clear answer from Support on this, maybe someone >here has some good advice or insight... > >Our FAS3020C filers often display CP types of "D" in a sysstat listing. >I get that this is a CP due to "log datavecs." Trying to understand >if this is a resource problem, or at least indicative of a performance issue: >CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk > ops/s in out read write read write age hit time ty util >17% 1166 12787 488 793 15683 0 0 >60 100% 55% D 12% >17% 937 13021 454 720 14376 0 0 >60 100% 49% D 10% >18% 1321 13167 538 697 14219 0 0 >60 100% 49% D 10% > >One thing I got from Support is that it might be indicative of bug >145410 (must actively reclaim resources). At their suggestion, I've >updated to DOT 7.0.3 (update from 7.0.2), but still see them a lot of the time. > >Is this pretty normal for the FAS3000 series? Thanks in advance. > >-- >Alan Sparks, UNIX/Linux Systems Integration and Administration ><asparks(a)doublesparks.net> > --=====================_1004222343==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Hi Alan, i meen that you reach this bug. I have the same on one of my customer site. And i have a huge number of this message. Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.index Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.value Sat Mar 11 23:04:11 CET [stk-hfm1: APIPool01:debug]: Removing too-old iterator file: /etc/.zapi/7537813126.next Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.index Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.value Sat Mar 11 23:35:49 CET [stk-hfm1: APIPool04:debug]: Removing too-old iterator file: /etc/.zapi/7539708117.next Sun Mar 12 00:00:00 CET [stk-hfm1: kern.uptime.filer:info]:  12:00am up 87 days,  7:48 1447100364 NFS ops, 7295964634 CIFS ops, 4291 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops on others systems i have these messages before upgrading  to 7.0.3 or 7.1 as you see on one other system nothing Sat Mar 11 20:00:00 CET [grizzly: kern.uptime.filer:info]:   8:00pm up 49 days, 55 mins, 21659709149 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 21:00:00 CET [grizzly: kern.uptime.filer:info]:   9:00pm up 49 days,  1:55 21697185323 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 22:00:00 CET [grizzly: kern.uptime.filer:info]:  10:00pm up 49 days,  2:55 21732428903 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sat Mar 11 23:00:00 CET [grizzly: kern.uptime.filer:info]:  11:00pm up 49 days,  3:55 21761084021 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops Sun Mar 12 00:00:00 CET [grizzly: kern.uptime.filer:info]:  12:00am up 49 days,  4:55 21782379473 NFS ops, 0 CIFS ops, 1051 HTTP ops, 0 DAFS ops, 0 FCP ops, 0 iSCSI ops but i have no performance issues on both sites. Regards At 05:34 12/03/2006, Alan Sparks wrote: <blockquote type=cite class=cite cite="">Not been getting a clear answer from Support on this, maybe someone here has some good advice or insight... Our FAS3020C filers often display CP types of "D" in a sysstat listing.  I get that this is a CP due to "log datavecs."  Trying to understand if this is a resource problem, or at least indicative of a performance issue: CPU   Total    Net kB/s    Disk kB/s    Tape kB/s Cache Cache  CP  CP Disk       ops/s    in   out   read  write  read write   age   hit time ty util 17%    1166 12787   488    793  15683     0     0   >60  100%  55%  D  12% 17%     937 13021   454    720  14376     0     0   >60  100%  49%  D  10% 18%    1321 13167   538    697  14219     0     0   >60  100%  49%  D  10% One thing I got from Support is that it might be indicative of bug 145410 (must actively reclaim resources).  At their suggestion, I've updated to DOT 7.0.3 (update from 7.0.2), but still see them a lot of the time. Is this pretty normal for the FAS3000 series?   Thanks in advance. -- Alan Sparks, UNIX/Linux Systems Integration and Administration <asparks(a)doublesparks.net> </blockquote></body> </html> --=====================_1004222343==.ALT--

1 0

"D" CP types on FAS3020
by Alan Sparks 12 Mar '06

12 Mar '06

Not been getting a clear answer from Support on this, maybe someone here has some good advice or insight... Our FAS3020C filers often display CP types of "D" in a sysstat listing. I get that this is a CP due to "log datavecs." Trying to understand if this is a resource problem, or at least indicative of a performance issue: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 17% 1166 12787 488 793 15683 0 0 >60 100% 55% D 12% 17% 937 13021 454 720 14376 0 0 >60 100% 49% D 10% 18% 1321 13167 538 697 14219 0 0 >60 100% 49% D 10% One thing I got from Support is that it might be indicative of bug 145410 (must actively reclaim resources). At their suggestion, I've updated to DOT 7.0.3 (update from 7.0.2), but still see them a lot of the time. Is this pretty normal for the FAS3000 series? Thanks in advance. -- Alan Sparks, UNIX/Linux Systems Integration and Administration <asparks(a)doublesparks.net>

1 0

Hitachi SAN Systems
by Bret Jacobson 10 Mar '06

10 Mar '06

Has anyone had experience with Hitachi's SAN devices? What I have always heard is that their products are good but their support is terrible. Any experiences with these units and/or support? Thx. -- View this message in context: http://www.nabble.com/Hitachi-SAN-Systems-t1259642.html#a3341204 Sent from the Network Appliance - Toasters forum at Nabble.com.

3 2

RE: Hitachi SAN Systems
by Carter K. George 10 Mar '06

10 Mar '06

We do not find that to be true. Their storage is great, if expensive. But it is fast (probably the fastest, depending on which model you are talking about) block storage we have tested, and we have over 40 different Fibre Channel arrays here in our lab. It has also been rock solid, and support has been fine. If you are used to the EMC Symmetrix model, where the EMC service and support guy has to come out to your site if you want to do so much as reconfigure a LUN, then it may feel like HDS is doing less to support you. In our shop, we don't want that - we like being able to configure our own LUNs and tune the array(s) ourselves. As far as break/fix support, HDS has been fine. We have a Thunder 9585V and an NSC 55 (new TagmaStor architecture). These are both smokin' fast arrays for block storage. Carter -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Bret Jacobson Sent: Friday, March 10, 2006 7:42 AM To: toasters(a)mathworks.com Subject: Hitachi SAN Systems Has anyone had experience with Hitachi's SAN devices? What I have always heard is that their products are good but their support is terrible. Any experiences with these units and/or support? Thx. -- View this message in context: http://www.nabble.com/Hitachi-SAN-Systems-t1259642.html#a3341204 Sent from the Network Appliance - Toasters forum at Nabble.com.

1 0

RE: Hitachi SAN Systems
by Ben Rockwood 10 Mar '06

10 Mar '06

In order to manage an HDS you require an externeal management system. For this reason I refuse to use an HDS. Frankly, when I tested their storage products, in their labs, I wasn't impressed with throughput. If you need midrange SAN storage I recommend looking at the Sun StorEdge 3510. You can manage it directly on the device, is easy to work with, pretty flexable, low cost, and has 8 Fibre ports on the box itself, making it perfect for situations where you don't have enough systems to justify buying a fabric switch. benr. -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of Bret Jacobson Sent: Fri 3/10/2006 7:42 AM To: toasters(a)mathworks.com Cc: Subject: Hitachi SAN Systems Has anyone had experience with Hitachi's SAN devices? What I have always heard is that their products are good but their support is terrible. Any experiences with these units and/or support? Thx. -- View this message in context: http://www.nabble.com/Hitachi-SAN-Systems-t1259642.html#a3341204 Sent from the Network Appliance - Toasters forum at Nabble.com.

1 0

ServerProtect for NetApps: Alerting Users
by Sewell, Cathy 10 Mar '06

10 Mar '06

We are using TrendMicro's ServerProtect for NetApps to virus scan all files incoming/outgoing from our NetApps Filers. As expected, when a user attempts to store a file containing malware on a Filer, ServerProtect appropriately takes action on the file (attempting to clean it, then, if that fails, quarantining or deleting the file). While ServerProtect does have some limited alerting capabilities and we do have it setup to alert our IS group when a file is quarantined or deleted, ServerProtect is apparently unable to alert the user - the person who was attempting to store the file on the Filer. Vscan on the Filer initiates the scan of the file, handing it off to the ServerProtect server for scanning, apparently without user information. From the user's perspective, they copy or move a file to the Filer and the file completely disappears with no explanation. The Filer's Vscan does give ServerProtect the originating computer's name. However, using something like "net send <computer name>" is not an option for us as the Messaging service is disabled on our user's Windows workstations. Additionally our users work from a variety of OSes, making an e-mail based solution most desirable. If you've faced this situation, we'd like to know what you've successfully setup to alert users. Thank you for your ideas -

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
22
Older →

Jump to page:

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 March 2006