From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 24 11:40:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4BC416A41F for ; Thu, 24 Nov 2005 11:40:53 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7675743D66 for ; Thu, 24 Nov 2005 11:40:49 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id jAOBce76089500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Nov 2005 12:38:40 +0100 (CET) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id jAOBceqL089499 for freebsd-hackers@freebsd.org; Thu, 24 Nov 2005 12:38:40 +0100 (CET) (envelope-from csaba) Date: Thu, 24 Nov 2005 12:38:40 +0100 From: Csaba Henk To: freebsd-hackers@freebsd.org Message-ID: <20051124113840.GK2911@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: misteries of find(1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2005 11:40:54 -0000 Hi! With fuse based filesystems I experienced find(1) giving up after running for a while, bursting out in a series of "File does not exist" complaints. (On the contrary, gfind just ran peacefully.) Why so? Well, fuse is a synthetic filesystem, where files themselves are subject to on demand creation / garbage collection (ie., not on the vnode level, but on the "backing storage" level, which role is played by the userspace filesystem daemon). As the ENOENT complaints came when file gc hit in, I conjectured that find somehow caches name-inode mappings (which becomes invalid if a file gets gc'd: after that, if it's asked for, it will reappear with a new inode number). I didn't look into find or libc source code, but that's what I think. Now with my CURRENT system (of 13th Nov) I don't see this happening anymore, BSD find also runs fine. I wonder what has changed... find itself doesn't seem to have any essential commits recently. Does anyone has an idea? Regards, Csaba