Hello,
I've run into a snapshot bug and was wondering if anyone else had. The details are basically that the filer ( an F520 with 128 Gb of disk, 128 Mb RAM, a Dec ALPHA CPU and running ONTAP 5.1D3) hangs when creating snapshots as instructed by BudTool. It is an ONTAP problem and is stopping me from doing backups.
Has anyone else been hit with this ?
:)
+--- In a previous state of mind, "Raymond Brennan" ray_brennan@mentorg.com wrote: | | I've run into a snapshot bug and was wondering if anyone else had. The | details are basically that the filer ( an F520 with 128 Gb of disk, 128 Mb | RAM, a Dec ALPHA CPU and running ONTAP 5.1D3) hangs when creating snapshots | as instructed by BudTool. It is an ONTAP problem and is stopping me from | doing backups.
I am not yet running 5.x but I will venture a few comments:
- what do you mean by hangs? does the filer stop serving NFS and has to be rebooted?
- are you running snapshots? (options nosnap off)
- what is your current disk space utilization? Do you have enough disk space to create the snapshot?
- have you checked now.netapp.com for this bug?
- what sort of shelves (fcal or non)?
- what does the error log on the filer say?
Alex
-----Original Message----- From: Alexei Rodriguez [mailto:alexei@cancerman.cimedia.com] Sent: Thursday, August 13, 1998 3:12 PM To: Raymond Brennan Cc: toasters@mathworks.com Subject: Re: Snapshot Bug
+--- In a previous state of mind, "Raymond Brennan" ray_brennan@mentorg.com wrote: | | I've run into a snapshot bug and was wondering if anyone else had. The | details are basically that the filer ( an F520 with 128 Gb of disk, 128 Mb | RAM, a Dec ALPHA CPU and running ONTAP 5.1D3) hangs when creating snapshots | as instructed by BudTool. It is an ONTAP problem and is stopping me from | doing backups.
I am not yet running 5.x but I will venture a few comments:
- what do you mean by hangs? does the filer stop serving NFS and has to be rebooted?
By "hangs2, I mean "hangs". No NFS shares are usable and I can't telnet onto the filer. If I'm already telnetted on, the prompt doesn't respond. All I can do is ping it.
- are you running snapshots? (options nosnap off)
Yes, I'm running snapshots.
- what is your current disk space utilization? Do you have enough disk space to create the snapshot?
39% and yes
- have you checked now.netapp.com for this bug?
yes I've checked. no, it isn't on there.
- what sort of shelves (fcal or non)?
Gray ones(honestly)
- what does the error log on the filer say?
Nothing.
Network Appliance have a great support setup, whom I trust implicitly. They are working on resolving this ASAP and the service I have had from them to date has far exceeded anything from other vendors of similar products. I am fully confident that they will provide a reliable, simple to apply fix very soon, as with everything up to now. I have been fully appraised of the exact nature of the bug itself-snapshot creation/management. They are responsible enough not to post stuff on web pages until they are sure it works in a real environment. I'll write to this group and yourself to let you know when I'm running backups again and how easy this problem was to fix.
Raymond Brennan, Software QA and Systems Engineer, Mentor Graphics Corp., R & D Engineering Group, Newbury, UK. (And A very satisfied customer)
Alex
+--- In a previous state of mind, "Raymond Brennan" ray_brennan@mentorg.com wrote: | | Network Appliance have a great support setup, whom I trust implicitly. They | are working on resolving this ASAP and the service I have had from them to | date has far exceeded anything from other vendors of similar products. I am | fully confident that they will provide a reliable, simple to apply fix very | soon, as with everything up to now. I have been fully appraised of the exact
Wow. This might end up on some marketing literature as a spontaneous testimonial :)
So, you found yourself a bug. I hope it gets fixed soon. Be warry of those pesky D patch releases. Make sure they actually test the patch. I had a less than enjoyable experience recently with the gigabit ethernet code and untested patches. I don't mind being a guinea pig, but not with production machines.
Most all fixes I have had to do relating to the filers involved upgrading the OS or the firmware. Relatively harmless (unless something goes wrong).
I remember with the first f540's having to get in the filer and flip some dip switches. Now there was some excitement :)
Alexei
Hello,
I've run into a snapshot bug and was wondering if anyone else had. The details are basically that the filer ( an F520 with 128 Gb of disk, 128 Mb RAM, a Dec ALPHA CPU and running ONTAP 5.1D3) hangs when creating snapshots as instructed by BudTool. It is an ONTAP problem and is stopping me from doing backups.
Has anyone else been hit with this ?
:)
Does this same behavior hit you when you do a regular "snap create" from the command line?
What sort of load is on your machine when you're doing these backups?
Stephen Manley File System Recovery
Due to some sloppy RTFMing, I apparently missed that as part of moving from one F520 to another I need to change every fscking client's home automounter map entries from
user server:/home/user
to
user server:/vol/vol0/home/user
(Or maybe try some symlink tricks but I'd really like to avoid that for efficiency and general non-grossness.)
<freak out>Aww, nutbunnies!<freak in>
There appears to be some backward-compatibility mode iff (and the manual isn't crystal-clear on this) you upgrade from 4.x to 5.x. Then apparently server:/home/user will still work.
But (he whines) what would've been so awful about making that a special case for (unupgraded) 5.x too? Rejiggering n+1 automounter maps is not my idea of a good time, and for various embarrassing reasons it's not just a matter of updating the NIS master or anything that simple.
Not to mention explaining to certain people here who have /net/server/home hardwired into their heads that they'll have to use the oh-so-intuitive /net/server/vol/vol0/home instead...
There appears to be some backward-compatibility mode iff (and the manual isn't crystal-clear on this) you upgrade from 4.x to 5.x. Then apparently server:/home/user will still work.
There is stuff that provide backwards compatibility, but it's not upgrade-specific; references to "/XXX" are treated as equivalent to "/vol/<root volume>/XXX".
If you upgrade from 4.x to 5.x, you presumably have a 4.x-style "/etc/exports" file, without the "/vol/<volume name>" stuff in it, so what shows up from a "show me your exports list" RPC request to the mount daemon is a set of pathnames without the "/vol/<volume name>" stuff.
However, if you install 5.x from scratch, the exports list created by the setup code has the "/vol/vol0" stuff in it for the root volume, so that shows up in the exports list.
You can undo that in the exports file, and it should work - e.g., you could export "/home" rather than "/vol/vol0/home" (or whatever you call the root volume - you don't have to call it "vol0").
On Thu, 13 Aug 1998, Guy Harris wrote:
You can undo that in the exports file, and it should work - e.g., you could export "/home" rather than "/vol/vol0/home" (or whatever you call the root volume - you don't have to call it "vol0").
Bingo. Dropping back to the old /, /home setup in /etc/exports works just fine on our (now 5.0.2) F520. Thanks!
If you want to cut a floppy for this under Solaris, it looks like you'll need to toss in a 'conv=sync' to the dd command. Otherwise, dd grumbles about an incomplete record and the updater says "CRC mismatch".
It would be nice if the download page included checksums for this file, and System V checksums for the boot floppy files.
Our new F520 has a conventional exports file, something like
/ -access=our.admin.host,root=our.admin.host /home -access=our.admin.host:some.other.machine:root=...
Standard stuff, just like the older F520 here. (Same admin.host, in fact.) But on our.admin.host, the root filesystem persistently is coming up read-only.
Kinda makes editing files in etc difficult.
The admin.host is running Solaris 2.6, current patches, and on the older F520 editing stuff in etc works just fine. Running 'snoop rpc mountd' on the admin.host hasn't turned up anything enlightening (to me, at least).
Any ideas? This is a busy system so rebooting from floppy to bypass the rc file and then trying another admin host is something I'd like to avoid, though at this stage I don't see an alternative.