From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 28 13:48:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C5251065670 for ; Wed, 28 Oct 2009 13:48:49 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1A68FC17 for ; Wed, 28 Oct 2009 13:48:49 +0000 (UTC) Received: by vws3 with SMTP id 3so65540vws.3 for ; Wed, 28 Oct 2009 06:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6XtEUVuNh8WIlTBu7+sZ0YqJkG9gPPT5lTb402+IWOE=; b=xX5A9EEgGW2rAIyrNqhkOMUq6Nm+JdfBRMcFrOMuDS3Q+cszHbGyljJ+uqj+6bkrA7 Hk9XxlaDnXs5sJEjZAGO+xX1sB9/u2pfyxhYrdj2lKFaExFH2W/cuW81hy+ROjKQyXRG DbCEZHrz27Zl7XXvnruh8hwKouoA0lnxRgkjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hF5Ox1S2gaqCuRwBzpPsYlkBYIZPz5mEULH/KHaT02gJZfpR/LX79Li71klbFw6Knf W8KXvSZZqpr6PhfcuZtFlnXIFmAjMe4jsbv6hih40dIv8+PrNfYbBIbH7T3t9GxUf/uv wS7+EwZCzMWbunLJJgS/Tk/l4EJKxUNT8TKJ8= MIME-Version: 1.0 Received: by 10.220.124.88 with SMTP id t24mr11245079vcr.67.1256737728383; Wed, 28 Oct 2009 06:48:48 -0700 (PDT) In-Reply-To: <20091028124832.GA7852@pm513-1.comsys.ntu-kpi.kiev.ua> References: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> <20091028124832.GA7852@pm513-1.comsys.ntu-kpi.kiev.ua> Date: Wed, 28 Oct 2009 09:48:48 -0400 Message-ID: <237c27100910280648k597e2159sf4fd663fe7b77b3b@mail.gmail.com> From: Linda Messerschmidt To: Andrey Simonenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 7.2 + NFS + nullfs + unlink + fstat = Stale NFS File Handle 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: Wed, 28 Oct 2009 13:48:49 -0000 On Wed, Oct 28, 2009 at 8:48 AM, Andrey Simonenko wrote: > As I understand when a file is opened in NULLFS its vnode gets new > reference on 'count of users', but this new reference is not propagated > to the lower vnode (vnode that is under NULLFS). =A0When a file is remove= d > NULLFS passes this op to the lower FS (NFS in this example) and that > FS sees that its vnode has only a single reference on 'count of users'. > > In case of NFS when there is a request to remove a vnode it checks that > value of 'count of users' for this vnode. =A0If this count is equal to 1, > then NFS client code does 'RPC remove'. =A0If this count is greater than = 1 > (for example when a file is opened), then NFS client code renames pathnam= e > to .nfs-file, but does not send 'RPC remove' to the NFS server. That sounds like a pretty reasonable explanation of what's going on. Unfortunately it does sound like this would be tough to fix. Since NFS deletes are a special case, short of making an NFS-aware nullfs, which seems silly, it sounds like the "solution" would be rewriting nullfs to propagate the reference count. I don't know enough about nullfs to know exactly how hard that would be, but I'm guessing it's not the work of a lazy afternoon. :-) >> =A0 =A0 =A0 if (!fd) { > =A0 =A0 =A0 =A0 =A0 ^^^^^ should be (fd < 0) Oops, you are right! Thanks very much!