NetApp felt it was very important to first identify the root cause and then define a corrective action plan before notifying our dedupe users.
Waiting until you find a corrective plan of action before notifying users is a poor idea. What about users (like we were) that were right about to start running asis on some production volumes on ontap 7.2.3.
On Thu, Apr 10, 2008 at 11:16 PM, Freeman, Larry Larry.Freeman@netapp.com wrote:
Hi Stephan, regarding the issue you've described below, we are in the process of writing a Customer Service Bulletin and notifying users that all dedupe (A-SIS) systems require a mandatory upgrade to 7.2.4. I don't want to diminish the severity of this issue, but I think its important to point out that very few users have experienced panics as a result of this, but of course if you are one of those few that has...that is of little consolation. I apologize for the aggravation this issue caused you.
NetApp felt it was very important to first identify the root cause and then define a corrective action plan before notifying our dedupe users. The corrective action plan will include the above mentioned upgrade to 7.2.4 and also tools for users to scan and repair any inconsistencies in their ACL or directory metadata without having to live through the kind of experience you were faced with. I'd also like to mention that no file data corruption occurs as a result of this issue, only inconsistencies between metadata and data blocks which can be detected and repaired with the maintenance tools we will provide. Again, not trying to diminish the seriousness of this issue, believe me it has a very high priority at NetApp.
Notifications will begin next week. If anyone else on toasters has questions about this issue or would like more info, please contact NetApp Customer Support.
Thanks,
Larry Freeman NetApp
From: "Darragh, Stephen J (CSC) (US SSA)" stephen.j.darragh@baesystems.com Date: April 10, 2008 8:04:33 AM PDT To: toasters@mathworks.com Subject: Serious A-sis bugs
If you are running a-sis with 7.2.3 or 7.2.3, there are a few bugs that can cause the filer to panic and mark that volume offline forcing a wafl_check on the containing aggregate. Not only that, but we had to netboot a developer release and had extensive outages.
We have been told that 7.2.4 had fixed these bugs, but if you have run asis on an old version, the bug may be there dormant.
I believe these were the bugs that were identified in our incident report.
bug 256799 Bug 266312 Bug 276084 bug 266312 bug 251673
The bug hit our primary storage, and it also his the VSM volumes on our DR filer, and it would is in the ACL/directory of the backup tapes as well.