From owner-freebsd-stable@FreeBSD.ORG Tue Jul 1 19:22:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A900881 for ; Tue, 1 Jul 2014 19:22:02 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4E8425B4 for ; Tue, 1 Jul 2014 19:22:01 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id F34C3B8093; Tue, 1 Jul 2014 21:21:58 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E1D8028497; Tue, 1 Jul 2014 21:21:58 +0200 (CEST) Date: Tue, 1 Jul 2014 21:21:58 +0200 From: Jilles Tjoelker To: Kimmo Paasiala Subject: Re: Odd problem with find(1) on FUSE sshfs mounted filesystems Message-ID: <20140701192158.GA18628@stack.nl> References: <996494CC-21F5-4476-8E5E-22F5E5E673DD@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <996494CC-21F5-4476-8E5E-22F5E5E673DD@icloud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:22:02 -0000 On Fri, Jun 13, 2014 at 09:49:13AM +0300, Kimmo Paasiala wrote: > I’m on FreeBSD stable/10 r267390 on one of my systems and on FreeBSD > 10.0-RELEASE-p5 i386 on another one. Both exhibit a strange behaviour > when find(1) is used on a FUSE sshfs mounted filesystems. This an > excerpt of a log from such run (I mounted FreeBSD sources on /mnt > using sshfs): > ... > mnt/contrib/ofed/libmlx4/autogen.sh^M > /mnt/contrib/ofed/libmlx4/mlx4.driver^M > /mnt/contrib/ofed/libmlx4/config^M > /mnt/contrib/ofed/libmlx4/Makefile.am^M > /mnt/contrib/openresolv^M > find: /mnt/contrib/openresolv/pdnsd.in: No such file or directory^M > find: /mnt/contrib/openresolv/resolvconf.8.in: No such file or directory^M > find: /mnt/contrib/openresolv/resolvconf.conf.5.in: No such file or directory^M > find: /mnt/contrib/openresolv/configure: No such file or directory^M > find: /mnt/contrib/openresolv/unbound.in: No such file or directory^M > find: /mnt/contrib/openresolv/named.in: No such file or directory^M > find: /mnt/contrib/openresolv/resolvconf.conf: No such file or directory^M > find: /mnt/contrib/openresolv/dnsmasq.in: No such file or directory^M > find: /mnt/contrib/openresolv/Makefile: No such file or directory^M > find: /mnt/contrib/openresolv/libc.in: No such file or directory^M > find: /mnt/contrib/openresolv/README: No such file or directory^M > find: /mnt/contrib/openresolv/resolvconf.in: No such file or directory^M > find: /mnt/contrib/openresolv: No such file or directory^M > /mnt/contrib/ntp^M > … > I can rsync(1) the files from the mounted filesystem just fine without > any errors/corruption so clearly all the files and directories are > there and accessible. > Is this a problem in FUSE/sshfs or find(1) and how to start debugging > this? > I have tested with both FreeBSD and OS X as SSH servers and the same > problem is present using both systems. > In all of the tests I’ve done there are no mountpoints crossed, each > mounted directory tree is on a single filesystem on the server. This is likely a problem in FUSE or sshfs. A potentially important difference between rsync(1) and find(1) is that find(1) changes directory as it traverses (except with -L or if it cannot open the current directory) while rsync(1) does not change directories and accesses all files using pathnames that start with the pathname you give it. Try running find(1) under ktrace(1) and looking for the exact situation where failures occur. Apart from -L (follow all symlinks), find(1) may also significantly change its behaviour when it needs to stat(2) everything, such as when -ls is given. Most base system utilities that support recursive directory traversal (usually the -R option) use the same fts(3) code as find(1), though some never change directory or stat everything always or never. -- Jilles Tjoelker