exportfs -a causes VCS panic

[seno]

Has anyone seen this?  I create new volumes on the appliance, modify the exports file and then do an "exportfs -a".  At that point Veritas Cluster Services log an error  "5 06:39:00 [host name] nfs: [ID 897781 kern.notice] NFS write error on host [filer name]: Permission denied."  At this point the database crashes and fails over to another host.

This doesn't seem like it should be happening.

System: FAS3140c

OnTap: 7.3.1

[chriskranz]

What are the mount options on the host side? If you use "exportfs -av" what is the output shown?

[byakimowicz]

What does your exports file entry look like for the volume/qtree in question?

[pascalduk]

Because these kind of problems in the past I never use exportfs -a, but only use exportfs for the volumes/qtrees that changed.

And even though exportfs -a does not unexport unchanged entries and the manuals say it is safe, the access cache for all entries is flushed just like running exportfs -f. This is bad because all host lookups need to be re-looked up and, depending on the workload, this can cause permission denied problems.

Therefore you should change your way of working and only re-export changed entries only on at a time.

[seno]

Thanks Pascal.  This is the method we decided on, as we can't have our production VCS cluster going down.

[byakimowicz]

Not sure if this helps or not, but we found this bug which is supposedly fixed, but we see almost the exact same behavior.

bugid - 155052

We have seen this specific issue about 8 times in the past few years.  It has caused some substantial outages.  The most recent was last week.  We are only exporting specifc qtrees now.