From owner-freebsd-fs@freebsd.org Thu Apr 29 11:18:36 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE69B623CAF for ; Thu, 29 Apr 2021 11:18:36 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FWCfz6RR2z4ZTh for ; Thu, 29 Apr 2021 11:18:35 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8d/PpHBGaxtRYmrSTUhySYQuPNnbp0eFTxJQ0WVHL2k=; b=n+6HwXCI/8JqVo9U3Ppbe9D5AG NlYW2BdEVhtf64onYHVGBsim2+Zwzt837FmtrB8dIpu92qfBaxuIOyW8ukmiD3sS5b8sruk303kA8 dVvtLtDtPDTkIUGvNMcBaDVTrBFWKnANLHQTY6QDBjRcvZtw+1SDFb8zU+DiTfLFzbPk=; Subject: Re: readdir() -> d_type always zero on NFS v3 mounted filesystems To: freebsd-fs@freebsd.org References: <2E84A420CCC10A73504624DE@triton.njm.me.uk> From: Ronald Klop Message-ID: <78c159ef-947a-8e2f-53bf-8d27b80193bf@klop.ws> Date: Thu, 29 Apr 2021 13:14:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2E84A420CCC10A73504624DE@triton.njm.me.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: / X-Spam-Score: -0.4 X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, BAYES_50, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A autolearn=disabled version=3.4.2 X-Scan-Signature: dd305f484f1ad876e240bae2a9803cbd X-Rspamd-Queue-Id: 4FWCfz6RR2z4ZTh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=n+6HwXCI; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[195.190.28.88:from]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 11:18:37 -0000 On 4/29/21 10:24 AM, N.J. Mann wrote: > Hi, > > > 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 > I thought it was an issue with gitup itself, but now I believe it is > 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); > } > } > > 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. > Nice analysis. The manual page dirent(5) says: "BUGS The usage of the member d_type of struct dirent is unportable as it is FreeBSD-specific. It also may fail on certain file systems, for example the cd9660 file system. " I think gitup would be more standards compliant if it used stat(2) for determining the type of a file/dir. An issue about this can best be reported at the upstream project: https://github.com/johnmehr/gitup . If the NFS server/client can implement d_type is outside of my knowledge. Regards, Ronald.