There is a very non-trivial fix in the works for this problem. It is undergoing some massive testing right now and will appear in a future release of ONTAP. I don't have the exact release number yet.
To remove a file with no disruptions in service, we sometimes have customers use the following PERL script. It uses "truncate" which actually sends "setattr" requests via NFS instead of "remove" requests. Do not try to truncate the entire file in one execution. That will only result in the same problem you are seeing with a remove.
---cut--- #!/usr/local/bin/perl5 # # large file remove/delete # # For bug 4157. This script allows a user to "lop off" pieces of # a large file until the file is gone. Typically, it is prudent to # lop off about 50 megs at a time until the file is a manageable # size, then it can be removed. (Note, I simply grabbed # the 50 meg figure out of my hat.) #
unless(defined($ARGV[0]) && defined($ARGV[1])) { die "Usage: truncate <filename> <amount to tuncate by>\n"; }
if($ARGV[1]=~/[^0-9]/) { die "Usage: truncate <filename> <amount to tuncate by>\n"; }
die "$ARGV[0]: $!\n" unless(-f $ARGV[0]);
truncate ($ARGV[0], ( (-s $ARGV[0]) - $ARGV[1])) || die "$ARGV[0]: $!\n"; ---cut---
Michael Douglass wrote:
On Fri, Aug 01, 1997 at 03:57:11PM +0200, sthaug@nethelp.no said:
I have seen this while gzipping many _large_ log files. Our filer is running 4.0.1c on an F220 with NFS only (no CIFS or HTTP).
Aug 1 15:37:22 snipp unix: NFS server snapp not responding still trying Aug 1 15:37:22 snipp unix: NFS server snapp ok
-- Michael Douglass Texas Networking, Inc.
<de> 'hail sparc, full of rammage' <de> 'the kernel is with thee' <de> 'blessed art thou amongst processors'