toasters September 1998

toasters@lists.teaparty.net

55 participants
54 discussions

Start a nNew thread

what is the safest way to shutdown the system?
by leila.mutevelic＠rss.rockwell.com 08 Sep '98

08 Sep '98

What would be the safest way to shutdown the system? Thanks, --Leila.

3 2

CODA support on NetApp
by Dan Bethe 06 Sep '98

06 Sep '98

Hi there everyone. What is the likelihood of NetApp ever supporting the CODA filesystem? http://www.coda.cs.cmu.edu Thanks! ` ~ ^ ' ~ ' ` ^ ~ ~ ^ ' ~ ` ` ~ ' ^ ` ~ ~ ` " ` ~ ' ^ " ^ ` ~ ' ~ ^ " ' ~ ` ^ ~ "If I seem too inconclusive, well it's just because it's so elusive." This email has been licensed by the GPL (http://www.gnu.org/philosophy) Dan ((((now seeking a Linux/Unix sysadmin job in Silicon Valley!)))) Bethe

5 6

Re: CODA support on NetApp
by Daniel Quinlan 05 Sep '98

05 Sep '98

Dan Bethe <dtm(a)hex.net> writes: >> Hi there everyone. What is the likelihood of NetApp ever >> supporting the CODA filesystem? >> http://www.coda.cs.cmu.edu Brian Pawlowski <beepy(a)netapp.com> writes: > As in grandson of AFS, disconnected operation? > > I'm curious, who is supporting it now? Many of our engineers who encounter problems using NFS have asked us about CODA and AFS. I am more interested in fixing some of the problems we encounter with NFS rather than introducing new ones, but CODA might be the answer. So, does NetApp have a better answer? - Dan

1 0

volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

I just got in an F630 with 5.0.2 and four fully-loaded differential shelves. Yowza. It showed up with one volume, vol0, two RAID groups (one for each pair of shelves, I guess), and only two disks in use, in vol0. I want to live dangerously, with one big volume and one RAID group for it. After all, that's how my other F630's running 4.x are configured, and it's worked fine for a long time. So naturally I did something stooopid. I (a) added all the disks, except for a spare, to vol0, (b) set the RAID group size of vol0 to 26, and then (c) noticed in the 5.x documentation that setting the RAID group size AFTER the fact don't do squat. :-( I might have had a prayer if I'd done (b) then (a). Here's what I have now: pacer> sysconfig -r Volume vol0 RAID group 0 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8b.13 8600/17612800 8683/17783240 data 8b.14 8600/17612800 8683/17783240 data 8b.1 8600/17612800 8683/17783240 data 8a.1 8600/17612800 8683/17783240 data 8a.2 8600/17612800 8683/17783240 data 8a.3 8600/17612800 8683/17783240 data 8a.4 8600/17612800 8683/17783240 data 8a.5 8600/17612800 8683/17783240 data 8a.8 8600/17612800 8683/17783240 data 8a.9 8600/17612800 8683/17783240 data 8a.10 8600/17612800 8683/17783240 data 8a.11 8600/17612800 8683/17783240 data 8a.12 8600/17612800 8683/17783240 data 8a.13 8600/17612800 8683/17783240 RAID group 1 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8b.2 8600/17612800 8683/17783240 data 8a.14 8600/17612800 8683/17783240 data 8b.3 8600/17612800 8683/17783240 data 8b.4 8600/17612800 8683/17783240 data 8b.5 8600/17612800 8683/17783240 data 8b.8 8600/17612800 8683/17783240 data 8b.9 8600/17612800 8683/17783240 data 8b.10 8600/17612800 8683/17783240 data 8b.11 8600/17612800 8683/17783240 data 8b.12 8600/17612800 8683/17783240 Spare disks RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- spare 8b.0 0 8683/17783240 spare 8a.0 0 8683/17783240 And what I want to have is only one RAID group, 0, with one parity and one spare. It looks like I am going to have to clobber vol0 and start over. Am I right? Anybody have experience with offlining then destroying vol0? Brian Rice brice(a)gnac.com

6 7

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

Mike Horwath <drechsau(a)tiny.net> writes: > So, with 2 raid groups...it is all still one filesystem? It can be with either one filesystem or two (each one with a single RAID group). There is a nice picture and explanation at: http://www.netapp.com/technology/level3/3027.html To avoid fragmentation problems (as in "I have 50 GB free on one filesystem and 50 GB free on another, but I need 100 GB in one place"), all of our filers are single volume (filesystem). Using multiple RAID groups is a much easier decision. Dan

1 0

Re: volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

Actually, I thought of another way to get one RAID group: wipe the filer, install 4.x on it, and then uprev it... B-) I am a big fan of having only one configuration, where possible. My other filers are at 4.3.4 right now, and when I upgrade those to 5.1Dx, they will have only one RAID group. I see no reason for this one to be special. My F630's have among them thousands 'n' thousands of hours of run time. I have yet to see a single disk failure, let alone a double-disk failure (knock knock). And I have no plans to put more shelves on them. Finally, if I have one more RAID group, that'll mean one more hot spare plus one more parity disk. When you take into account the purchase of my entire F630, two disks set aside for safety have an opportunity cost (at list prices) of just over $12,000. Is that safety worth $12,000 to me? Well, maybe it is: the not-backed-up-yet data on the rest of a RAID group could exceed $12,000 in replacement value. And maybe it isn't: these failures seem unlikely enough to make that $12,000 feel like earthquake insurance in Bismarck, N.D. Guess this is for me to figure out, huh? Brian

2 1

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

hitz(a)netapp.com (Dave Hitz) writes: > But in addition, RAID reconstruction is much faster. When you > reconstruct a failed drive, you have to read all the data on all the > other drives, so if your RAID groups are half as big, then the > reconstruction goes twice as fast. My experience is that reconstruction is more than twice as fast. More like quadruple, depending on server load and size of the RAID group. Does NetApp have recent numbers on reconstruct time? Especially under various NFS loads (reading/writing to disk, not just cache, so the disks are loaded as well). Dan

1 0

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

Dave Hitz wrote: >> So at one parity disk per 14 the overhead is 1/14 = 7%, and at one >> parity disk per 26 the overhead is 3.8%. Brian Rice <brice(a)gnac.com> writes: > The cost per usable gigabyte of my F630's has received *considerable* > executive scrutiny recently. So I'm just a leeeetle sensitive about this > kind of thing. You *really* want to use one RAID group per 14 disks. Trust me. Right now, we have 3 F630 systems (40 disk SCSI, 40 disk SCSI, and 26 disk FC). On our first F630, we have a 26 disk RAID group because multiple RAID groups weren't available at the time. On that RAID group, disk reconstructions seem to take forever. Once it took 23 hours, under only moderate load. I tried cranking the raid.reconstruct_speed dial higher (I think I had it set to 3), but then everyone starting getting "nfs server not responding" errors. So, not only are you subject to greater risk during those 23 hours, but your users will complain about how slow everything is (even if the dial is set at 2 or 3). Let's face it, NetApps don't perform very well during disk reconstruction. On a 14 disk RAID group on an F630, the slowest reconstruction we've finished in under 4 hours. The fastest was under 2 hours (on the F630 FC). I guess it's important to note that disk reconstruction speed does not increase linearly. Double the disks in a RAID group and it can easily quadruple the time. Dan

1 0

Re: volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

Dave Hitz wrote: > So at one parity disk per 14 the overhead is 1/14 = 7%, and at one > parity disk per 26 the overhead is 3.8%. The cost per usable gigabyte of my F630's has received *considerable* executive scrutiny recently. So I'm just a leeeetle sensitive about this kind of thing. > So are you dead-set on living dangerously? Maybe, maybe not. My experience with my existing (identical) F630's suggests I can get away with it. On the other hand, it's bad karma to turn away a life jacket when somebody offers you one "just in case." So I dunno. Let's say, for the sake of argument, that I did decide to live dangerously. So...what's the best way to get a vol0 with one RAID group in it? Brian brice(a)gnac.com

1 0

Re: Support for Network Time Protocol?
by sirbruce＠ix.netcom.com 04 Sep '98

04 Sep '98

On 09/04/98 00:12:22 you wrote: > >I thought this follow-up (to a thread from several months ago) might be >interesting for people at sites that stress time synchronization. > >Daniel Quinlan <quinlan(a)transmeta.com> wrote: > >> 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). > >So, I started monitoring the time with the kludgey method of creating a >file and using stat() on it. I wasn't very happy with that method >because it tended to give false alerts, so I eventually disabled it. > >Earlier this week, we had another problem with time synchronization. It >wasn't actually the NetApp, but I still had to rule it out because it >wasn't being monitored. I tried port-scanning a NetApp, looking for some >hidden protocol that might let me reliably query the time. Here's what I >found: > > port tcp udp > ----- ----------- ----------- > 23 telnet - > 80 http - > 111 sunrpc sunrpc > 137 - netbios-ns > 138 - netbios-dgm > 139 netbios-ssn - > 161 - snmp > 514 shell syslog > 520 - route > 602 - unknown > 603 unknown - > 604 - unknown > 605 unknown - > 606 - unknown > 607 unknown - > 608 - unknown > 609 unknown - > 618 - unknown > 619 - unknown > 620 unknown - > 1063 - unknown > 2049 nfs nfs > 10000 unknown - > >A lot of unknown services (ones not listed in /etc/services, some are >probably NDMP. I thought the 600 ports were for rsh, but by they alternate between TCP and UDP, and aren't contiguous, I don't know. I have no idea what 10000 is for. Bruce

4 3

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