toasters

toasters@lists.teaparty.net

13515 discussions

RE: following unix soft links
by Muhlestein, Mark 09 Jan '01

09 Jan '01

Thanks for posting the good comments, Steve. The name of the config file is /etc/symlink.translations, and it's used to map "rooted" symlinks (i.e. they start with "/"). This is all covered in the documentation. We are developing a solution to this that allows you to securely follow links that leave a share. We'll let folks know when that becomes available. Or watch for bug 15808 to be fixed :-) Mark Muhlestein -- mmm(a)netapp.com > -----Original Message----- > From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] > Sent: Tuesday, January 09, 2001 8:33 AM > To: Coder, James (STP) > Cc: toasters(a)mathworks.com > Subject: Re: following unix soft links > > > > The filer does indeed understand and follow symlinks. Just be > sure the symlink "makes sense" from the filer's perspective. > > Note that under NFS, the filer simply sends the value of the > symlink to the client and the client actually follows it. > So under NFS the filer acts just like any other NFS server with > regard to symlinks. > > Under CIFS, however, the client does not know what a symlink is, > so the filer itself must follow it. So the symlink must "make sense" > to the filer. > > Check out these options in the man pages and Sys. Admin. Guide > > options cifs.home_dir > options cifs.symlinks.enable > options cifs.symlinks.cycleguard > > There is also a file you can create (forgot the name) that the > filer uses to translate symlinks so that they make sense to > the filer. > > To prevent users from circumventing security using symlink tricks, > the filer will not follow all symlinks. But it should follow > any symlink that refers back to the same share, provided the > user has permissions to follow it. And the symlink must make > sense to the filer, so relative symlinks are better than absolute > ones, eg, foo -> ../bar/baz > > Obviously, any symlink that triggers an automount is not going > to work unless the data is on the same filer and you can come up > with a translation that works. > > The cifs.home_dir option is very handy if you have a lot of users. > It allows you to automatically create a share for each user's > home directory. That way a user can attach to \\FILER\loginid > and get straight into their home directory. All the home > directories must have the same name as the loginid and must > be directly beneath the cifs.home_dir directory. You can get > around this restriction by using a directory of symlinks instead. > The symlinks can cross volumes, but not filers. For example, > set up the option like this: > > options cifs.home_dir /vol/vol0/shares > > Assume user bill's home directory is in /vol/vol0/h1/b/bi/bill > > Set up this symlink on the filer: > > /vol/vol0/shares/bill -> /vol/vol0/h1/b/bi/bill > > Now bill can simply attach to \\FILER\bill to get into his > home directory. > > > > I recently moved users from a Solaris home server to our > 760 (6.0.1.r1). > > filer. The users had created soft links (ln -s) to > directories (either > > within their home directory or to other points via the automounter). > > Previously the Unix home shares were shared via samba and > Unix users in the > > Windows environment could follow a soft link to the directory. > > > > With the data moved to the NetApp, this is no longer > available when using > > CIFS. I opened a case with NetApp and basically the answer > was - that's > > right - the filer won't follow the link to a directory. > > > > I have toyed with the idea of using samba on a box and > letting the user > > point to it, thus letting samba provide the share service. > Have not tried > > this, but was wondering if anyone has? Does anyone know of > a work-around > > for this? > > > > Thx in advance for any replies. > > > > JCC > > > > > > > > > > James C. Coder > > UNIX Administrator > > Guidant Corporation > > Phone: 651-582-4797 > > Email: james.coder(a)guidant.com <mailto:james.coder@guidant.com> > > > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 > > University of Virginia ITC Unix Support >

1 0

RE: CIFS and win not res kit SU cmd
by Jankowski Ted-CTJ012 09 Jan '01

09 Jan '01

If you try connecting to the NetApp via IP address, you should be able to log in with a second set of credentials, while keeping your first connection (via name). -Ted -----Original Message----- From: Larry Nail [mailto:lnail@ti.com] Sent: Monday, January 08, 2001 7:40 PM To: neil lehrer; toasters Subject: Re: cifs and win nt res kit SU cmd You can only have 1 set of logon credentials for a file system connection (UNC or Mapped drive) to another CIFS system per logon session (Terminal Server handles logon sessions differently). If you're connected to \\filer\share as nlehrer with your regular account, your credentials will be domain\nlehrer until you disconnect from that system (closing a window doesn't necessarily disconnect you). To connect to the same filer with another logon account, you need to unmount all your connections. You can do this with Windows Explorer (Disconnect Mapped Drive) but that doesn't always show all the connections, so I recommend that you use NET USE to display your drive connections, then use " net use \\filer\<sharename> /d " for each connection to the filer (including ipc$). You can at that point use Windoze Explorer to map a network drive using other credentials (you can not do this from a 9x client) or use " net use \\filer\ipc$ /user:domainname\username password " (you can skip the password if you'd like & you should be prompted). ----- Original Message ----- From: "neil lehrer" <nlehrer(a)ibb.gov> To: "toasters" <toasters(a)mathworks.com> Sent: Wednesday, December 27, 2000 1:00 PM Subject: cifs and win nt res kit SU cmd : hi, : : i am just bringing up an f760 cluster with cifs and nfs. i had just configured : my shares and went to edit some of the files in \etc with wordpad and found that : i was getting access denied, but could edit them when going thru nfs and using : vi. : : after checking a bunch of things it turned out that something wasn't happy about : the way i was accessing the files - using the SU cmd in the nt 4 res kit. : normally i log into my nt machine locally and if i want to do any domain admin : stuff i just open a cmd window and SU to my domain admin acct. saves me from : rebooting or using another machine. in this case i can SU and use srvmgr : against the filer with no problem, but actually editing files that require : administrator privileges doesn't work. i do have the correct mappings in : usermap.cfg and editing does work properly if i do a "normal" domain admin : login. : : any ideas? anybody ever get this to work? : : i really like being able to use SU this way and [in the past] it made it easy to : test access against other ids without moving to another machine or rebooting? : thanks. : : -- : : : regards :

1 0

RE: following unix soft links
by Benn, Paul 09 Jan '01

09 Jan '01

James, Windows (CIFS) clients should indeed be able to follow UNIX symlinks as long as the symlinks do not point to a directory outside of the CIFS share point. This is done to maintain the security of other shares (like, say, c$). I haven't played with Samba in a while but it may operate in a similar way. Regards, Paul Benn Network Appliance -----Original Message----- From: Coder, James (STP) [mailto:james.coder@guidant.com] Sent: Tuesday, January 09, 2001 7:00 AM To: toasters(a)mathworks.com Subject: following unix soft links I recently moved users from a Solaris home server to our 760 (6.0.1.r1). filer. The users had created soft links (ln -s) to directories (either within their home directory or to other points via the automounter). Previously the Unix home shares were shared via samba and Unix users in the Windows environment could follow a soft link to the directory. With the data moved to the NetApp, this is no longer available when using CIFS. I opened a case with NetApp and basically the answer was - that's right - the filer won't follow the link to a directory. I have toyed with the idea of using samba on a box and letting the user point to it, thus letting samba provide the share service. Have not tried this, but was wondering if anyone has? Does anyone know of a work-around for this? Thx in advance for any replies. JCC James C. Coder UNIX Administrator Guidant Corporation Phone: 651-582-4797 Email: james.coder(a)guidant.com <mailto:james.coder@guidant.com>

1 0

Preposterous date/time stamp
by Thomas.L.White＠chase.com 09 Jan '01

09 Jan '01

Well - we have the honor of wearing the egg on our face. I found out from the NT group this a.m. that the files in question exist on the Novell server has these files with future dates already. thanks and sorry for the red herring. tw ---------------------- Forwarded by Thomas L. White/CHASE on 01/09/2001 11:13 AM --------------------------- Thomas.L.White@chase.com@mathworks.com on 01/08/2001 01:48:21 PM Sent by: owner-toasters(a)mathworks.com To: toasters(a)mathworks.com cc: Subject: Preposterous date/time stamp I seem to recall reading about this on the list - but could not find any related emails. Does anyone know of a bug and or fix for the date stamp on files/directories on the filer showing up as 20 to 30 years in the future ? The users are still being migrated to the filers from their old Novell or NT "homes" so this may even be due to "copy method" I'm not sure at this point We have not managed to replicate the error on "command". thanks tw

1 0

RE: following unix soft links
by Traitel, Eyal 09 Jan '01

09 Jan '01

James, 1. A Samba host is able to follow ALL symlinks, including those to automounter directories since it's a user level application, that uses the underline NFS client when needed. A filer is only an NFS server, thus it cannot follow symlinks like: /net/other_host 2. The filer has the /etc/symlink.translations feature, which lets you solve specific link needs. 3. You can use Samba as a workaround, but the better way to handle this is clean the past, and remove old links that are in no need when the data is centralized. As something that I've done in a real-life environment, you'll be amazed how many links-to-nowhere you currently have. By the way - this is a system-slower also, as many users often have long PATH variables that goes to many such non-existing non-existing directories. Hope it helps, Eyal. ---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Eyal Traitel - Filer Escalation Engineer CNA, MCSE, CSA, NetApp CA Network Appliance BV Holland Office Center Kruisweg 799b 2132 NG, Hoofddorp The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Email: eyal(a)netapp.com ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ---------------------------------------------------------------------- -----Original Message----- From: Coder, James (STP) [mailto:james.coder@guidant.com] Sent: Tuesday, January 09, 2001 4:00 PM To: toasters(a)mathworks.com Subject: following unix soft links I recently moved users from a Solaris home server to our 760 (6.0.1.r1). filer. The users had created soft links (ln -s) to directories (either within their home directory or to other points via the automounter). Previously the Unix home shares were shared via samba and Unix users in the Windows environment could follow a soft link to the directory. With the data moved to the NetApp, this is no longer available when using CIFS. I opened a case with NetApp and basically the answer was - that's right - the filer won't follow the link to a directory. I have toyed with the idea of using samba on a box and letting the user point to it, thus letting samba provide the share service. Have not tried this, but was wondering if anyone has? Does anyone know of a work-around for this? Thx in advance for any replies. JCC James C. Coder UNIX Administrator Guidant Corporation Phone: 651-582-4797 Email: james.coder(a)guidant.com <mailto:james.coder@guidant.com>

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 09 Jan '01

09 Jan '01

Spinning up and down isn't the issue. According to the warning displayed when you do a disk_fw_update, even upgrading a single disk, "It involves... suspending all disk I/O to all disks while that is happening" SUSPENDING ALL DISK I/O TO **ALL** (not ONE) DISKS. That's a problem in my environment. So I guess the question is, is the notice wrong and when you're only doing a disk_fw_update on a single disk that's allocated as a spare, it doesn't suspend I/O to ALL disks? ONTAP 6 will be very cool. I'm looking forward to being able to install it soon. I particularly appreciate the new logging features so I can see who did what when. Thanks, MD -----Original Message----- From: Krause, Oliver To: 'Tom "Mad Dog" Yergeau'; 'toasters(a)mathworks.com' Sent: 1/8/01 3:50 PM Subject: RE: disk_fw_update issue with 840-5.3.7R2 As i said you can upgrade a single disk with "disk_fw_update <disk>" without service disruption while this disk is a spare. Again, you have to specify the disk. Also does a disk firmware upgrade not take 2 minutes per disk if you use disk_fw_update. Oliver BTW: ONTAP 6.0 and higher is supposed to do a automatic update when you insert a disk with older firmware (have not tried it yet). Cool, isn't it?

3 2

RE: HSM
by Cormier, Darleen 09 Jan '01

09 Jan '01

Hi Steve, The reason that neither Veritas Storage Replicator or other HSM packages currently support HSM migration of data to and from NetApp filers is because DataONTAP does NOT support DMAPI protocol. DMAPI means Data Management Application Programming Interface and this along with the X/Open Data Storage Management (XDSM) standard allow HSM functionality across a wide range of operating environments without sacrificing system reliability. Without this, the HSM software has no idea of file attributes or location. This reason I'm giving you all this exciting info (YAWN) is that most, if not all, HSM packages use these protocols. Until NetApp is able to support these protocols, or the 3rd party companies are able to come up with some other way of doing HSM, we will not be able to offer an HSM solution to our customers. Now, Good news/ Bad News. The good news is we are receiving more and more requests for this functionality, and I do know that engineering is looking at possibly adding support for the DMAPI protocol. The bad news is that no date has been set for beginning to implement this. Sorry we can't tell you anything better. -----Original Message----- From: SteveRoche(a)datalink.com [mailto:SteveRoche@datalink.com] Sent: Monday, January 08, 2001 12:22 PM To: toasters(a)mathworks.com Subject: HSM Hello everyone! We are considering implementing an F840 with around 4TB into a mixed UNIX and Win2K environment. My question to this much respected community is can we implement an HSM solution like say Veritas Storage Replicator to extract stale files and put them out to tape with a Netapp? I have been told know but am hoping yes. Thanks in advance Steve Roche sroche(a)datalink.com

2 1

cifs and win nt res kit SU cmd
by neil lehrer 09 Jan '01

09 Jan '01

hi, i am just bringing up an f760 cluster with cifs and nfs. i had just configured my shares and went to edit some of the files in \etc with wordpad and found that i was getting access denied, but could edit them when going thru nfs and using vi. after checking a bunch of things it turned out that something wasn't happy about the way i was accessing the files - using the SU cmd in the nt 4 res kit. normally i log into my nt machine locally and if i want to do any domain admin stuff i just open a cmd window and SU to my domain admin acct. saves me from rebooting or using another machine. in this case i can SU and use srvmgr against the filer with no problem, but actually editing files that require administrator privileges doesn't work. i do have the correct mappings in usermap.cfg and editing does work properly if i do a "normal" domain admin login. any ideas? anybody ever get this to work? i really like being able to use SU this way and [in the past] it made it easy to test access against other ids without moving to another machine or rebooting? thanks. -- regards

3 2

RE: disk_fw_update issue with 840-5.3.7R2
by Krause, Oliver 08 Jan '01

08 Jan '01

As i said you can upgrade a single disk with "disk_fw_update <disk>" without service disruption while this disk is a spare. Again, you have to specify the disk. Also does a disk firmware upgrade not take 2 minutes per disk if you use disk_fw_update. Oliver BTW: ONTAP 6.0 and higher is supposed to do a automatic update when you insert a disk with older firmware (have not tried it yet). Cool, isn't it? > -----Original Message----- > From: Tom "Mad Dog" Yergeau [mailto:MadDog@fool.com] > Sent: Montag, 8. Januar 2001 17:39 > To: 'Krause, Oliver'; 'toasters(a)mathworks.com' > Subject: RE: disk_fw_update issue with 840-5.3.7R2 > > > Just upgrading one disk still takes downtime for the whole > system. The > filer may be up, but if I can't access my data, effectively, > it's down. > > "Downloading disk firmware can be disruptive to the system. > It involves spinning down and then spinning up all > affected disks, and suspending all disk I/O to all disks while > that is happening. This may take up to 2 minutes to complete. > This delay may cause clients to hang, and may cause > CIFS clients to drop sessions." > > It should be noted that this notice can be misleading. It > actually takes up > to two minutes PER TYPE OF DISK to complete a disk_fw_update. > So if you > have two models of 18 GB drives and two models of 36 GB > drives, if can take > up to eight minutes to flash the firmware. Been there, done > that. Was a > little surprised the first time. :) > > Since replacement disks often ship with firmware different > than the level > currently being used on a filer, it would be nice if > (a) NetApp checked autosupport logs and pre-flashed the > firmware for you > before sending you the disk > (b) You could flash a single disk w/o disrupting all I/O for > the entire > filer. Especially if the disk is marked as a spare and > therefore not part > of any volume. > > If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or > something), this would be wild: flash firmware on a volume > one disk at a > time, and keep the volume online. While each disk is being > flashed, use the > parity disk to serve data, and keep track of writes somewhere > to get the > flashed disk back up to synch when the flash is done. > > It's too bad NetApp doesn't offer mirroring, since if you had > mirrored sets > this would be a real piece of cake. Just flash half a mirror > while the > other half served data. > > Online disk_fw_update would be a big help in five 9s environments. > > MD > > > > -----Original Message----- > From: Krause, Oliver [mailto:OKrause@netapp.com] > Sent: Saturday, January 06, 2001 5:56 AM > To: 'Premanshu Jain'; 'toasters(a)mathworks.com' > Subject: RE: disk_fw_update issue with 840-5.3.7R2 > > > You can specify which disk to upgrade. Try > > disk_fw_update <diskname> > > This works while the system is running. > > Oliver > > > -----Original Message----- > > From: Premanshu Jain [mailto:PrJain@shastanets.com] > > Sent: Freitag, 5. Januar 2001 23:31 > > To: 'toasters(a)mathworks.com' > > Subject: disk_fw_update issue with 840-5.3.7R2 > > > > > > I have a 840 cluster. Whenever I add new disks, the cluster > > starts throwing > > 'doenrev disk firmware' error messages. NetApps suggests doing a > > disk_fw_update on the disk and strictly says "NO need to Halt > > a filer'. > > Reality is totally different. The command specifically asks > > you wether the > > cluster partner is on Halt-OK prompt or not? > > > > The workaround I am doing, intitiate a takeover and do the > > disk_fw_update. > > However, this still needs to do a takeover/giveback and 2 minutes of > > downtime...Adding/replacing bad disks is a regular activity... > > > > Any suggestions..? > > >

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Witham, John 08 Jan '01

08 Jan '01

I may be wrong, but here's the scenario I envision when you're talking about this: a) Disk Fails b) RMA c) New disk arrives, with old firmware. d) Disk added as HotSpare - DOWNREV DISKS PRESENT! error abounds. At this point, the new drive is a hotspare. If it's the only downrev disk, you could safely do a disk_fw_update, and it would take just the hotspare offline and upgrade it. I would be on the safe side and specify the disk to upgrade, but all in all, the Filer is still alive and serving data. The key phrase below is "It involves spinning down and then spinning up all AFFECTED disks". -john John Witham MCSE, MCP+i, A+ Senior Systems Engineer Takeda Pharmaceuticals America, Inc. V://847.383.3304 F://847.383.3205 mailto://jwitham@takedapharm.com -----Original Message----- From: Tom "Mad Dog" Yergeau [mailto:MadDog@fool.com] Sent: Monday, January 08, 2001 10:39 AM To: 'Krause, Oliver'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 Just upgrading one disk still takes downtime for the whole system. The filer may be up, but if I can't access my data, effectively, it's down. "Downloading disk firmware can be disruptive to the system. It involves spinning down and then spinning up all affected disks, and suspending all disk I/O to all disks while that is happening. This may take up to 2 minutes to complete. This delay may cause clients to hang, and may cause CIFS clients to drop sessions." It should be noted that this notice can be misleading. It actually takes up to two minutes PER TYPE OF DISK to complete a disk_fw_update. So if you have two models of 18 GB drives and two models of 36 GB drives, if can take up to eight minutes to flash the firmware. Been there, done that. Was a little surprised the first time. :) Since replacement disks often ship with firmware different than the level currently being used on a filer, it would be nice if (a) NetApp checked autosupport logs and pre-flashed the firmware for you before sending you the disk (b) You could flash a single disk w/o disrupting all I/O for the entire filer. Especially if the disk is marked as a spare and therefore not part of any volume. If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or something), this would be wild: flash firmware on a volume one disk at a time, and keep the volume online. While each disk is being flashed, use the parity disk to serve data, and keep track of writes somewhere to get the flashed disk back up to synch when the flash is done. It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets this would be a real piece of cake. Just flash half a mirror while the other half served data. Online disk_fw_update would be a big help in five 9s environments. MD -----Original Message----- From: Krause, Oliver [mailto:OKrause@netapp.com] Sent: Saturday, January 06, 2001 5:56 AM To: 'Premanshu Jain'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

1 0

HSM
by SteveRoche＠datalink.com 08 Jan '01

08 Jan '01

Hello everyone! We are considering implementing an F840 with around 4TB into a mixed UNIX and Win2K environment. My question to this much respected community is can we implement an HSM solution like say Veritas Storage Replicator to extract stale files and put them out to tape with a Netapp? I have been told know but am hoping yes. Thanks in advance Steve Roche sroche(a)datalink.com

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

SnapMirror wouldn't work for what I've suggested as it is read-only asynch. A read/write synchronous mirror (i.e. RAID 4+1) would be required for what I suggested. Also, to avoid disruption to the client systems, the CIFS share name or NFS export could not be changed during the fw_update, so it would have to be the same set of data and not a snapmirror. Thus even a synchronous snapmirror wouldn't work, unless you could make the snapmirror read/write, re-direct clients to the mirror on the fly without breaking the TCP session, and then reverse-synch once the disk_fw_update was done and put the clients back on the original disks. That'd be quite a trick! Think 99.999% uptime, no disruption to clients for *ANYTHING*. Or at least nothing as common and (relatively) trivial as a firmware update. I'd still say NetApp should look at ASUP logs and pre-flash replacement disks to the level appropriate for your ONTAP version before shipping them to you. That's probably a lot easier to do in the short term than my ambitious on-the-fly firmware update suggestion. :) Hey--here's a technical question. SCSI RAID systems allow you to update the firmware on one disk without disruption I/O to the other disks. Is this possible on an FCAL loop? Or is the whole idea technically infeasible due to limitations in FCAL? MD -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Monday, January 08, 2001 2:21 PM To: Tom "Mad Dog" Yergeau; 'Krause, Oliver'; toasters(a)mathworks.com Subject: Re: disk_fw_update issue with 840-5.3.7R2 > It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets > this would be a real piece of cake. Just flash half a mirror while the > other half served data. Have you heard of something called SnapMirror? Bruce

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

Just upgrading one disk still takes downtime for the whole system. The filer may be up, but if I can't access my data, effectively, it's down. "Downloading disk firmware can be disruptive to the system. It involves spinning down and then spinning up all affected disks, and suspending all disk I/O to all disks while that is happening. This may take up to 2 minutes to complete. This delay may cause clients to hang, and may cause CIFS clients to drop sessions." It should be noted that this notice can be misleading. It actually takes up to two minutes PER TYPE OF DISK to complete a disk_fw_update. So if you have two models of 18 GB drives and two models of 36 GB drives, if can take up to eight minutes to flash the firmware. Been there, done that. Was a little surprised the first time. :) Since replacement disks often ship with firmware different than the level currently being used on a filer, it would be nice if (a) NetApp checked autosupport logs and pre-flashed the firmware for you before sending you the disk (b) You could flash a single disk w/o disrupting all I/O for the entire filer. Especially if the disk is marked as a spare and therefore not part of any volume. If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or something), this would be wild: flash firmware on a volume one disk at a time, and keep the volume online. While each disk is being flashed, use the parity disk to serve data, and keep track of writes somewhere to get the flashed disk back up to synch when the flash is done. It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets this would be a real piece of cake. Just flash half a mirror while the other half served data. Online disk_fw_update would be a big help in five 9s environments. MD -----Original Message----- From: Krause, Oliver [mailto:OKrause@netapp.com] Sent: Saturday, January 06, 2001 5:56 AM To: 'Premanshu Jain'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

2 1

Preposterous date/time stamp
by Thomas.L.White＠chase.com 08 Jan '01

08 Jan '01

I seem to recall reading about this on the list - but could not find any related emails. Does anyone know of a bug and or fix for the date stamp on files/directories on the filer showing up as 20 to 30 years in the future ? The users are still being migrated to the filers from their old Novell or NT "homes" so this may even be due to "copy method" I'm not sure at this point We have not managed to replicate the error on "command". thanks tw

1 0

RE: 72 Gig disks
by Mohler, Jeff 08 Jan '01

08 Jan '01

Like anything else, the sizing you are looking at for HDs can affect performance depending on what your application and read/write requirements/habits are. Its inaccurate to state "performance problems" as a global issue as "performance" means different things to different customers. Consult with your salesperson and thier SE..they will be glad to help you make the best decision to match your specific environment, or follow this thread..im sure we'll get into a healthy debate on this. *grin* Cheers!

3 4

disk_fw_update issue with 840-5.3.7R2
by Premanshu Jain 07 Jan '01

07 Jan '01

I have a 840 cluster. Whenever I add new disks, the cluster starts throwing 'doenrev disk firmware' error messages. NetApps suggests doing a disk_fw_update on the disk and strictly says "NO need to Halt a filer'. Reality is totally different. The command specifically asks you wether the cluster partner is on Halt-OK prompt or not? The workaround I am doing, intitiate a takeover and do the disk_fw_update. However, this still needs to do a takeover/giveback and 2 minutes of downtime...Adding/replacing bad disks is a regular activity... Any suggestions..?

3 2

RE: disk_fw_update issue with 840-5.3.7R2
by Krause, Oliver 06 Jan '01

06 Jan '01

You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

1 0

RE: 72 Gig disks
by Klinkner, Steve 05 Jan '01

05 Jan '01

> -----Original Message----- > From: Thomas Heffron [mailto:theffron@wisedata.com] > 2) They are not listed in the drop down when creating a generic volume in > the GUI (at least in 5.3.6 - don't know about 6.x). This is fixed in a 6.x point release that should ship in the next few months (bug is 28306). In a future release, the pull-down will display only a list of spare sizes which actually appear on the system (which in all cases makes more sense than the canned list it currently displays). ---------------------------------------------------------------------- steve klinkner klink(a)netapp.com

1 0

72 Gig disks
by Geoff Hardin 05 Jan '01

05 Jan '01

Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

4 3

RE: 72 Gig disks
by Kitch, David 05 Jan '01

05 Jan '01

They're available on the new systems, but they don't recommend them for performance reasons. Regards, David Kitch Texas Instruments Incorporated IS dkitch(a)ti.com -----Original Message----- From: Geoff Hardin [mailto:geoff.hardin@dalsemi.com] Sent: Friday, January 05, 2001 1:29 PM To: toasters(a)mathworks.com Subject: 72 Gig disks Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

1 0

RE: Slooow SGI Challenge
by Fox, Adam 04 Jan '01

04 Jan '01

Personally, I'm a big fan of packet traces. They can tell you alot. In this case, you have one good performing client, and one bad one. Take a packet trace of each and compare them. What sizes are the clients requesting? What calls are they using? Is the client just not generating requests very quickly? Just some thoughts.. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Link, Bill (OTS-EDH) [mailto:Bill_Link@billing.com] > Sent: Thursday, January 04, 2001 4:57 PM > To: 'toasters(a)mathworks.com' > Subject: Slooow SGI Challenge > > > > Has anyone had any experience with netapp on an SGI Challenge system? > > I have an F760 attached through a cisco 4000 switch to an sgi > challenge and > an IBM S7A. I have this arrangement on a dedicated subnet with all > interfaces set manually to 100tx. (The vme controller in the > SGI will not > abide full duplex). The netapp is running 5.3.6R1, the SGI is > running IRIX > 6.5.5, and the RS6K is running AIX4.3.3. > > The IBM will create a 128M file in under 30 sec. If I mount > the filer on the > SGI box and specify tcp it takes about 2 min 45 sec to write > the same file. > If I let the mount on the SGI default to udp it won't write > more that 15 or > 20 mb before it starts getting nfs timeouts. The filer seems > oblivious to > any trouble that the sgi is having. The sgi will work > (slowly) at 10mb half > duplex with udp. > > Any suggestions would be much appreciated. > > Bill Link > SysAdmin > Output Technology Solutions > bill_link(a)billing.com > >

1 0

RE: Slooow SGI Challenge
by Miller, James 04 Jan '01

04 Jan '01

Hi Bill: I spent 7 years field service for SGI. You have 2 problems, neither can be fixed. 1)The VME 100Mb (C8-100BT)interface turned out to be a piece of junk even before IRIX 6.5 got hold of it. The board, as you said is only half duplex, a seven year old design that never got a major rework because it's on a long time dead product line. I had several sites that were never able to exceed 65Mb simplex. 2) IRIX 6.5 has made problems and performance worse that under IRIX 6.2 For systems under SGI support, GPS would swap out the C8-100BT board for a FDDI (SAS/DAS) of their choice and Customer would use a CISCO, or alike, to run a FDDI Fibre connection into a 100Mb switch. There are some kernel parameters to tweak for this that I cannot remember for MTU. We did this for 2 customers just in the Phila area alone because of the additional problems IRIX 6.5.x created. FIX, Replace your Challenge with a O2100 and get reliable 100 & 1000Mb FDX interfaces. ... All is my humble opinion, and not that of my previous employer ..jim -----Original Message----- From: Link, Bill (OTS-EDH) [mailto:Bill_Link@billing.com] Sent: Thursday, January 04, 2001 4:57 PM To: 'toasters(a)mathworks.com' Subject: Slooow SGI Challenge Has anyone had any experience with netapp on an SGI Challenge system? I have an F760 attached through a cisco 4000 switch to an sgi challenge and an IBM S7A. I have this arrangement on a dedicated subnet with all interfaces set manually to 100tx. (The vme controller in the SGI will not abide full duplex). The netapp is running 5.3.6R1, the SGI is running IRIX 6.5.5, and the RS6K is running AIX4.3.3. The IBM will create a 128M file in under 30 sec. If I mount the filer on the SGI box and specify tcp it takes about 2 min 45 sec to write the same file. If I let the mount on the SGI default to udp it won't write more that 15 or 20 mb before it starts getting nfs timeouts. The filer seems oblivious to any trouble that the sgi is having. The sgi will work (slowly) at 10mb half duplex with udp. Any suggestions would be much appreciated. Bill Link SysAdmin Output Technology Solutions bill_link(a)billing.com

1 0

Slooow SGI Challenge
by Link, Bill (OTS-EDH) 04 Jan '01

04 Jan '01

Has anyone had any experience with netapp on an SGI Challenge system? I have an F760 attached through a cisco 4000 switch to an sgi challenge and an IBM S7A. I have this arrangement on a dedicated subnet with all interfaces set manually to 100tx. (The vme controller in the SGI will not abide full duplex). The netapp is running 5.3.6R1, the SGI is running IRIX 6.5.5, and the RS6K is running AIX4.3.3. The IBM will create a 128M file in under 30 sec. If I mount the filer on the SGI box and specify tcp it takes about 2 min 45 sec to write the same file. If I let the mount on the SGI default to udp it won't write more that 15 or 20 mb before it starts getting nfs timeouts. The filer seems oblivious to any trouble that the sgi is having. The sgi will work (slowly) at 10mb half duplex with udp. Any suggestions would be much appreciated. Bill Link SysAdmin Output Technology Solutions bill_link(a)billing.com

1 0

Dump dies around 13G bytes
by Fred Ab 04 Jan '01

04 Jan '01

I get DUMP IS ABORTED when trying to dump a 39G byte volume to a DLT 7000 drive directly connected to the NetApp. I know that it is 35G native and 70G compressed but it looks like it dies around 13G. DUMP: creating "/vol/vol1/.snapshot/snapshot_for_backup.109" snapshot. DUMP: Using Partial Volume Dump DUMP: Date of this level 0 dump: Fri Dec 22 23:05:09 2000. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol1/proj to /dev/nrst0a DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 38916473 tape blocks on 0.97 tapes DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: We have written 1585525 KB to tape. DUMP: We have written 3465622 KB to tape. DUMP: We have written 5328897 KB to tape. DUMP: We have written 7627776 KB to tape. DUMP: We have written 10240766 KB to tape. DUMP: DUMP IS ABORTED ultra119# pwd /america/vol1/proj ultra119# df -k . Filesystem kbytes used avail capacity Mounted on america:/vol/vol1 53766696 39259976 14506720 74% /america/vol1 sysconfig -t output: nrst0a - no rewind device, format is: 85937 bpi 70 GB (w/comp) Dump Command = dump 0ubBf 63 39845869 /dev/nrst0a Any ideas why?

1 0

Gotcha on multiple network interfaces
by Brian L. Brush 04 Jan '01

04 Jan '01

If you have multiple network interfaces on your filers, this information may be useful to you. If you're thorough about reading the documentation and clever about checking your results, you may have discovered it for yourself. While testing our new F760 cluster, we have discovered that if the filer has two interfaces on the same subnet and the default gateway resides on that subnet, the default route in the filer's routing table will choose the interface with the lower number. In particular, using the "setup" command, we configured an F760 with on-board 100Mbps e0 and GigE e7 on the same subnet. Using "netstat -r", we determined that the default route was using e0, which was not what we wanted--the 100Mbps was intended to be a backup link, not for regular production use: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 1 61 e0 127 localhost UG 1 9 lo localhost localhost UH 1 0 lo 135.90.100/24 link#1 UC 0 0 e0 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e0 135.90.100.255 link#1 UHL 1 46 e0 After some experimentation, we settled on editing /etc/rc to configure e0 after both configuring e7 and adding the default route; we also turned off routed: #Auto-generated by setup Wed Dec 20 19:16:53 GMT 2000 hostname pow ifconfig e7 `hostname`-e7 flowcontrol full netmask 255.255.255.0 route add default 135.90.100.254 1 ifconfig e0 `hostname`-e0 mediatype auto netmask 255.255.255.0 #routed on options dns.domainname is.paradyne.com options dns.enable on options nis.domainname is.paradyne.com options nis.enable on savecore exportfs -a nfs on Now we have the results we wanted; all outbound packets should use the gig link, according to netstat: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 5 2148 e7 127 localhost UG 1 261 lo localhost localhost UH 1 0 lo 135.90.100/24 link#2 UC 0 0 e7 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e7 135.90.100.255 link#2 UHL 1 1794 e7 Looking at the systems we had in production, we realized that, as a result of this oversight, they had been sending all outbound traffic via their fast ethernet interfaces rather than gig! Aaargh! --Brian L. Brush Senior Systems Administrator Paradyne Corporation

1 1

Jump to page:

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