On Thu, Apr 20, 2000 at 11:37:35AM -0400, Kelly Wyatt wrote:
We upgraded out filers to NetApp Release 5.3.4R3P2 this weekend. Since
then, NBU 3.2 keeps downing the tape drives on several, but not all of the filers (3 of 9). This seems to happen before, during and after backups.
Has anyone else seen this? Thanks!!
we saw this on previous versions of NBU, 3.1.*, the work around was really
lame. cron executed a script which did something like: vmoprcmd -up # for each drive.
Hi there!
We also have the same problem with this release of Ontap and Netbackup v3.2. According to Netapp the cause of this problem is a faulty Java Class (Garbage collection) which NDMP uses. This should also be the reason for the problems with Ontap 5.3.5xxx, where the problem got critical and backup stopped working.
Netapp recommended us to switch to Ontap 5.3.5R2P1, where the NDMP-BUG is (hopefully) fixed.
regards, Klaus Micheler Infineon Technologies DC
Yeah- we too are having all kinds of backup related problems with the one filer we have upgraded to 5.3.5R2P1. In our case, we can't back up the machine at all.
Aaarrgh, this one really hurts. Not to mention the fact that NetApp had us upgrade to this version partially because of ECC errors we were getting. This is a brandy new F760 to boot.
I'm not looking forward to begging for the downtime needed to fix this one. It'll be like...
Me: "Uh, hi, um- we need some dowwntime one of the Filers." Them: "Why?" Me: "Ah- because we can't back it up suddenly." Them: "What!?- How long has THIS been going on?" Me: "Since we upgraded the OS last Friday." Them: "You mean that we could lose data from as far back as Friday?" Me: "Unfortunately. Yes."
... Well you all get the picture. I guess I'm just venting because not being able to backup a filer is a PRETTY BIG BUG!
Derek Kelly
On 5/2/00 at 8:10 AM, Klaus.Micheler@infineon.com (Micheler Klaus (MDCA Villach)) wrote:
On Thu, Apr 20, 2000 at 11:37:35AM -0400, Kelly Wyatt wrote:
We upgraded out filers to NetApp Release 5.3.4R3P2 this weekend.
Since then, NBU 3.2 keeps downing the tape drives on several, but not all of the filers (3 of 9). This seems to happen before, during and after backups.
Has anyone else seen this? Thanks!!
we saw this on previous versions of NBU, 3.1.*, the work around was
really
lame. cron executed a script which did something like: vmoprcmd -up
#
for
each drive.
Hi there!
We also have the same problem with this release of Ontap and Netbackup v3.2. According to Netapp the cause of this problem is a faulty Java Class (Garbage collection) which NDMP uses. This should also be the reason for the problems with Ontap 5.3.5xxx, where the problem got critical and backup stopped working.
Netapp recommended us to switch to Ontap 5.3.5R2P1, where the NDMP-BUG is (hopefully) fixed.
regards, Klaus Micheler Infineon Technologies DC
So - Does anyone want to venture an opinion as to how well 5.3.4R3 (no patch level) might work with NBU 3.2? I'm at a client running this configuration and I'd like to have at least a wild guess as to how well this is going to work. Unfortunately at the moment I'm stuck waiting for the delivery of some tape libraries so I'm trying to do as much ground work as possible on the implementation. I have a query in to Veritas but haven't heard back yet.
If this is problematic what is the closest match (probably backward) that will likely work??
"Micheler Klaus (MDCA Villach)" wrote:
On Thu, Apr 20, 2000 at 11:37:35AM -0400, Kelly Wyatt wrote:
We upgraded out filers to NetApp Release 5.3.4R3P2 this weekend. Since
then, NBU 3.2 keeps downing the tape drives on several, but not all of the filers (3 of 9). This seems to happen before, during and after backups.
Has anyone else seen this? Thanks!!
we saw this on previous versions of NBU, 3.1.*, the work around was really
lame. cron executed a script which did something like: vmoprcmd -up # for each drive.
Hi there!
We also have the same problem with this release of Ontap and Netbackup v3.2. According to Netapp the cause of this problem is a faulty Java Class (Garbage collection) which NDMP uses. This should also be the reason for the problems with Ontap 5.3.5xxx, where the problem got critical and backup stopped working.
Netapp recommended us to switch to Ontap 5.3.5R2P1, where the NDMP-BUG is (hopefully) fixed.
regards, Klaus Micheler Infineon Technologies DC
Hi,
We are using Ontap 5.3.4R3P2D4 successfully with NBU 3.2
Manny
Steve Hanson wrote:
So - Does anyone want to venture an opinion as to how well 5.3.4R3 (no patch level) might work with NBU 3.2? I'm at a client running this configuration and I'd like to have at least a wild guess as to how well this is going to work. Unfortunately at the moment I'm stuck waiting for the delivery of some tape libraries so I'm trying to do as much ground work as possible on the implementation. I have a query in to Veritas but haven't heard back yet.
If this is problematic what is the closest match (probably backward) that will likely work??
"Micheler Klaus (MDCA Villach)" wrote:
On Thu, Apr 20, 2000 at 11:37:35AM -0400, Kelly Wyatt wrote:
We upgraded out filers to NetApp Release 5.3.4R3P2 this weekend. Since
then, NBU 3.2 keeps downing the tape drives on several, but not all of the filers (3 of 9). This seems to happen before, during and after backups.
Has anyone else seen this? Thanks!!
we saw this on previous versions of NBU, 3.1.*, the work around was really
lame. cron executed a script which did something like: vmoprcmd -up # for each drive.
Hi there!
We also have the same problem with this release of Ontap and Netbackup v3.2. According to Netapp the cause of this problem is a faulty Java Class (Garbage collection) which NDMP uses. This should also be the reason for the problems with Ontap 5.3.5xxx, where the problem got critical and backup stopped working.
Netapp recommended us to switch to Ontap 5.3.5R2P1, where the NDMP-BUG is (hopefully) fixed.
regards, Klaus Micheler Infineon Technologies DC
Hi,
I ran the du -sk command once as root and once as an ordinary user. The results differed by several fold.
Is the reason that when running du as root the snapshots are calculated as well?
Running the quota report I see the same result as when the user executed the du command.
Menachem,
The du command does not report (or even complain ) about directories that it cannot enter. You should always be sure that the filesystem is mounted with root privileges before you use du to determine the space used by directory trees. Also be very careful of qtrees with NTFS security.
Sincerely, Paul Lupa
"Menachem Kaiser (r53417)" wrote:
Hi,
I ran the du -sk command once as root and once as an ordinary user. The results differed by several fold.
Is the reason that when running du as root the snapshots are calculated as well?
Running the quota report I see the same result as when the user executed the du command.
Manny.Kaiser@motorola.com writes:
I ran the du -sk command once as root and once as an ordinary user. The results differed by several fold.
Is this in Solaris 2+ or a similar SVR4-derived Unix? If so, the probable explanation is that there were directories unreadable by the "ordinary user" in the tree. du(1m) just leaves them out without a murmur unless you specify the -r option. Which, therefore, you should always do. Who was responsible for this lamebrained specification would be interesting to know... [it wasn't like that in SunOS4].
Is the reason that when running du as root the snapshots are calculated as well?
Not unless some snapshot directories are only-root-readable. Anwyay, the way to find out is to leave out the -s option and see what's being added up, surely?
Running the quota report I see the same result as when the user executed the du command.
What sort of quota: qtree or uid? If the latter, then perhaps the parts of the directory tree unreadable by the "ordinary user" are also not owned by her?
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
Chris Thompson -
Derek Kelly -
Menachem Kaiser -
Micheler Klaus (MDCA Villach) -
Paul Lupa (ra5507) -
Steve Hanson