[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-fs
Subject:    Re: readdir() -> d_type always zero on NFS v3 mounted filesystems
From:       Rick Macklem <rmacklem () uoguelph ! ca>
Date:       2021-04-29 14:39:10
Message-ID: YQXPR0101MB096836625A188C6751B3F5E6DD5F9 () YQXPR0101MB0968 ! CANPRD01 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

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.
--
_______________________________________________
freebsd-fs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]