Date: Thu, 29 Apr 2021 14:39:10 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "N.J. Mann" <njm@njm.me.uk>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: readdir() -> d_type always zero on NFS v3 mounted filesystems Message-ID: <YQXPR0101MB096836625A188C6751B3F5E6DD5F9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <2E84A420CCC10A73504624DE@triton.njm.me.uk> References: <2E84A420CCC10A73504624DE@triton.njm.me.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
N.J. Mann wrote: >I recently changed over from using svn to gitup to update /usr/ports >on my local system and have been experiencing problems since. At first >either a kernel issue or a configuration issue. I originally posted >about the problem to the freebsd-ports mailing list: >https://lists.freebsd.org/pipermail/freebsd-ports/2021-April/120929.html > >Since then I have dug deeper and come to the conclusion that it is not a >problem with gitup. > >The issue I am seeing is that gitup is unable to delete files and >directories, even complete ports, which have been removed from the >repository. gitup basically does the following: > >prune_tree(base_path) >{ >if ((directory = opendir(base_path)) != NULL) { > while ((entry = readdir(directory)) != NULL) { > snprintf(full_path, sizeof(full_path), "%s/%s", base_path, entry->d_name); > if (entry->d_type == DT_DIR) { > prune_tree(full_path); > } else { > if ((remove(full_path) != 0) && (errno != ENOENT)) > err(EXIT_FAILURE, "prune_tree: cannot remove %s", full_path); > } > } > closedir(directory); > if (rmdir(base_path) != 0) > err(EXIT_FAILURE, "prune_tree: cannot remove %s", base_path); > } >} The code should check for d_type == DT_UNKNOWN and then do stat() to find out the type, as Ronald noted. --> The d_type is normally filled in if you use the "rdirplus" NFS mount option, which might work around the issue. rick closedir() When gitup is run on either a UFS or ZFS file system this works. However, when I run it on a NFS v3 mounted filesystem it fails. Liberal addition of printf's shows that for non-NFS mounted filesystems d_type contains the correct value for each file/directory, but for NFS mounted file systems it is zero - other fields such as d_name and d_namlen are correct. While debugging this I added a call to stat() and that always returns the correct values. At this point I started digging in libc and quickly found that readdir() is basically a wrapper around a system call. Digging in the kernel I quickly got out of my depth and hence my posting here. I then wrote a simple test programme which also shows the issue. I have attached the source for the test programme and the output from two runs, the first on an NFS mounted file system and the second on a local UFS file system. Before gitup started failing I had not seen any failures like this and that was why I initially assumed this must be a gitup issue. I now believe this is either a kernel issue or a confuration issue. My configuration is as follows: file server: /exports/ports - ZFS file system for FreeBSD ports repo exported via NFS /remote/ports - FreeBSD ports repo NFS (v3 rw,tcp) mounted from /export/ports on file server /usr/ports - symbolic link to /remote/ports client machines: /remote/ports - FreeBSD ports repo NFS (v3 ro,tcp) mounted from /export/ports on file server /usr/ports - symbolic link to /remote/ports I run gitup in /remote/ports on the file server and then pkg, portmaster, &.c, in /usr/ports on the file server and then the client machines. All systems are running 11-STABLE from about 12 days ago - I usually update every couple of weeks. Any assistance, suggestions, patches, clue bats, will be gratefully accepted. Regards, Nick. --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB096836625A188C6751B3F5E6DD5F9>