From owner-freebsd-fs@freebsd.org Sun Dec 11 23:06:50 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3898DC72EC7 for ; Sun, 11 Dec 2016 23:06:50 +0000 (UTC) (envelope-from 01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@amazonses.com) Received: from a8-26.smtp-out.amazonses.com (a8-26.smtp-out.amazonses.com [54.240.8.26]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 017687DB for ; Sun, 11 Dec 2016 23:06:49 +0000 (UTC) (envelope-from 01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1481497602; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=bRUZ4MKqNhMAI5qxIkb6ySdOIiDoMZhcRomUdVRfj0A=; b=ktxDoPxs82q0pn7qr5FqWmcPY58IZB45oqWw0QWI6besKUWL0urP6ewUJxCWbwLJ TN9V8MN+5dfZ1oT/429Mq3a5glXFBU1MMdjSwNDG4RUGFG5HFQ/qnD91K/xVCPGyFly XAUd9/mP283FBo/Xz6P/XjRc8Axyw2cDP7rFzOdw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1481497602; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=bRUZ4MKqNhMAI5qxIkb6ySdOIiDoMZhcRomUdVRfj0A=; b=1IgsuVWCxLeND4EcBkJupW5ZW4wr1Jd1kxcwRSlZ6fdx1UrBLTnbmFr5YK44zCc3 kGZ7C59HyfTCrfBzpye+ti8eeTHVfcEwHBPg4KdIhNLoMOcSosAyyMM7BvJFeauJs5G ZjysbkU2rc7ySvUZBZfl8DsPez3Y/TP+jLOhF67s= To: "freebsd-fs@freebsd.org" From: Colin Percival Subject: ESTALE after cwd deleted by same NFS client Message-ID: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> Date: Sun, 11 Dec 2016 23:06:42 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.11-54.240.8.26 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 23:06:50 -0000 Hi filesystem gurus, If I run the following with /nfs/ being an NFS mount: # mkdir /nfs/foo # touch /nfs/foo/bar # cd /nfs/foo # rm -r /nfs/foo # rm bar Then the final 'rm bar' fails with 'Stale NFS file handle'. This results in 'make buildworld' with an NFS-backed /usr/obj failing during cleandir (which, for some reason, seems to delete the same directories multiple times.) I'm not sure if this is an NFS issue or a VFS issue, nor whether this is intended (but IMHO astonishing) behaviour or a bug. I realize that if the 'rm -r' was performed by a different NFS client, this is the behaviour which would be expected; but it seems to me that when the commands are executed by the same NFS client, it should be possible for the cached file handle for /nfs/foo to be invalidated when /nfs/foo is deleted, in order to return ENOENT instead of ESTALE here. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid