Bug 26142 - [nfs] Unlink fails on NFS mounted filesystem
Summary: [nfs] Unlink fails on NFS mounted filesystem
Status: Closed DUPLICATE of bug 57696
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 4.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: vwe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-03-27 11:30 UTC by j.schripsema
Modified: 2016-05-16 22:47 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description j.schripsema 2001-03-27 11:30:04 UTC
When removing all files in a large NFS mounted directory by calling
readdir and unlink repeatedly files get skipped.
It seems that this problem is related to problem kern/3381.
I ran into this problem when running bonnie++ (www.cooker.com.au/bonnie++)
on a NFS mounted filesystem.

Fix: 

Call rewinddir after each unlink call. I consider this a workaround,
not a fix.
How-To-Repeat: Run the attached program on the client. Uncomment the rewinddir call
first.

---- snip -----
#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <dirent.h>


#define BASEDIR "/FS/testdir"           /* NFS mounted  */
#define NFILES  1024

main()
{
        create_files();
        delete_files();
}

create_files()
{
        int i,fd;
        char buf[2048];

        for(i = 0 ; i < NFILES ; i++) {
                snprintf(buf,2048,"%s/%04d",BASEDIR,i);
                if ((fd = open(buf,O_CREAT | O_TRUNC | O_WRONLY, 0644)) < 0) {
                        perror(buf);
                        return(-1);
                }
                close(fd);
        }
}

delete_files()
{
        DIR *dirp;
        struct dirent *dp;
        char buf[2048];

        if ((dirp = opendir(BASEDIR)) == NULL) {
                perror("opendir");
                return (-1);
        }
        while ((dp = readdir(dirp)) != NULL) {
                if (dp->d_name[0] == '.')
                        continue;
                snprintf(buf,2048,"%s/%s",BASEDIR,dp->d_name);
                fprintf(stderr,"%s\n",buf);
                if (unlink(buf) < 0) {
                        perror(buf);
                        return (-1);
		}

		/* Workaround */   
                /* rewinddir(dirp); */
		/* End workaround */
	}
}
Comment 1 kris freebsd_committer 2003-11-15 21:50:55 UTC
State Changed
From-To: open->analyzed

See also kern/57696.  This is a known problem in the nfs code; 
the ufs code contains code to deal with this situation.  Bug peter  
for more details :-)
Comment 2 cel freebsd_committer 2006-05-13 01:08:01 UTC
Responsible Changed
From-To: freebsd-bugs->cel
Comment 3 cel freebsd_committer 2007-03-12 15:27:09 UTC
Responsible Changed
From-To: cel->freebsd-bugs

Back to the public pool.
Comment 4 kmacy freebsd_committer 2007-11-16 04:07:57 UTC
State Changed
From-To: analyzed->feedback


Needs new analysis. 


Comment 5 kmacy freebsd_committer 2007-11-16 04:07:57 UTC
Responsible Changed
From-To: freebsd-bugs->rwatson


Needs new analysis.
Comment 6 Robert Watson freebsd_committer 2008-03-02 14:48:06 UTC
Responsible Changed
From-To: rwatson->freebsd-bugs

Return to public pool; unfortunately, I don't have time to work on this 
issue currently.
Comment 7 vwe freebsd_committer 2008-05-11 15:51:59 UTC
Responsible Changed
From-To: freebsd-bugs->vwe


Dear submitter: Do you still see this problem with an actual released 
version? Over the years someone believed this problem might have gone 
but it's currently unsure if that's true. 

this ticket will be closed at the next after-EOL cleanup 
(scheduled for June) if it is not checked until then. 

-> track
Comment 8 Eitan Adler freebsd_committer 2012-01-14 15:48:20 UTC
State Changed
From-To: feedback->closed

per vwe
Comment 9 Bryan Drewery freebsd_committer 2016-05-16 22:45:45 UTC
This isn't really fixed, it's due to unlink inside readdir loop.

https://lists.freebsd.org/pipermail/freebsd-fs/2014-October/020155.html
Comment 10 Bryan Drewery freebsd_committer 2016-05-16 22:47:01 UTC
Duping to Bug 57696 which has better discussion.

*** This bug has been marked as a duplicate of bug 57696 ***