From owner-freebsd-fs@freebsd.org Thu Dec 22 00:24:43 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 C3738C8B8AE for ; Thu, 22 Dec 2016 00:24:43 +0000 (UTC) (envelope-from 0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@amazonses.com) Received: from a8-56.smtp-out.amazonses.com (a8-56.smtp-out.amazonses.com [54.240.8.56]) (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 88663886 for ; Thu, 22 Dec 2016 00:24:43 +0000 (UTC) (envelope-from 0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1482366281; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=7DfO7d+zmjsQdoq78KnYEN989hSCpuqrcpKj7eTlPog=; b=Lt0JjQucLSGFSSdrW3YxFMykoKcM5PaoJ2ef+vo9uwVIaw9JQESkPz1kqz7mZdvZ aupDNBNfL5LmlChPzamaBKp5gv0wIPFMQOflAlccNj0Rj/d7DkMkHExajCyQg8H3G0L HmXrvIeHq/+fcPVP9s9V4Q3MR7thEMGPauA30pVo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1482366281; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=7DfO7d+zmjsQdoq78KnYEN989hSCpuqrcpKj7eTlPog=; b=CSSc10195gymr4viDdIiRBrI77pohYd3bugWo4RYftUfR7RSXMg5Q30fMLQFWGy2 bFgGgNgIRa5J66HyGf/Q0WCCVBgsJkBPyF4zmQA6KxWfakTqjkQc61O4OFB8XTeM6gT EDlwX1Bw2LtWS/qodwiX6/DAJYnLgwWpnD8VLziA= Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem , Don Lewis References: <201612210325.uBL3PVtg006345@gw.catspoiler.org> <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> Cc: "freebsd-fs@freebsd.org" From: Colin Percival Message-ID: <0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@email.amazonses.com> Date: Thu, 22 Dec 2016 00:24:41 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.22-54.240.8.56 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: Thu, 22 Dec 2016 00:24:43 -0000 On 12/21/16 14:43, Rick Macklem wrote: >> On 12/20/16 19:25, Don Lewis wrote: >>> It sort of seems like this should be handled at the vfs level. Once >>> rmdir() succeeds, there should be no calls to the underlying fs code. >>> Maybe add a deleted flag to the vnode ... >> > As I already mentioned to Colin, there is also the case where another client did the > "rmdir" and the ESTALE will happen for that case, so mapping ESTALE->ENOENT > seems to me to be a simple (and maybe more general) solution for NFS. Except that ENOENT means "the named file does not exist", and ESTALE simply means "the file which had that name a while ago no longer exists". If you have one machine which calls open("foo") and another machine which calls rename("bar", "foo") then you can very reasonably expect to not get ENOENT. It seems to me that "behave like a local filesystem with respect to other operations from the same client, but return ESTALE if a different client rips files/directories out from underneath you" makes more sense than having ENOENT get returned when there is in fact a file with the specified name. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid