From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 08:56:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C3871065670 for ; Sat, 12 Jun 2010 08:56:14 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E03DF8FC1B for ; Sat, 12 Jun 2010 08:56:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so1161550bwz.13 for ; Sat, 12 Jun 2010 01:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=7HlmGkTm+AfSzAwGYxgssB6odoMov3JJqdAAOLJuIg0=; b=R7WRCBytKIdQo+pwxZA/Fdwz8jL7434p8Hh7TQrAHrBjzillbFczuxySjW+6/g8AX2 vkOyq/6lELANEsbe+gSo5AqOX/5mfrrrTGrHkG99iEf6mFInnOCJFH0Na1UTlH1aySfP cHciNoeo3P/HWH5RF2Y/4p+1xRI0lAi1PV8zI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=mnUwYl9PjcHy+ljuigCOUQFvFbgVspGNgDjlzPgNhjEuho/ruVXQIPxhbuGOMu3eE3 tEErnW918mIqtbBDdp3E6jFkr7XQidKWGwKnxN6N052m8Il6byFIhvnC3Qgcpp4lkPWa M9/NP4am+QeK/oWS/pYYIrd6LWKZs8deBSbc8= Received: by 10.204.83.198 with SMTP id g6mr2127081bkl.104.1276332972371; Sat, 12 Jun 2010 01:56:12 -0700 (PDT) Received: from localhost ([95.69.160.52]) by mx.google.com with ESMTPS id v2sm8926329bkz.7.2010.06.12.01.56.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 01:56:11 -0700 (PDT) From: Mikolaj Golub To: Leon =?utf-8?Q?Me=C3=9Fner?= References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> X-Comment-To: Leon =?utf-8?Q?Me=C3=9Fner?= Date: Sat, 12 Jun 2010 11:56:10 +0300 In-Reply-To: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> ("Leon =?utf-8?Q?Me=C3=9Fner=22's?= message of "Sun, 6 Jun 2010 16:44:43 +0200") Message-ID: <8639wsk4t1.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 08:56:14 -0000 On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me=C3=9Fner wrote: LM> Hi, LM> I hope this is not the wrong list to ask. Didn't get any answers on LM> -questions. LM> When you try to do the following inside a nullfs mounted directory, LM> where the nullfs origin is itself mounted via nfs you get an error: LM> # foo=20 LM> # tail -f foo&=20 LM> # rm -f foo=20 LM> tail: foo: Stale NFS file handle LM> # fg LM> This is really a problem when running services inside jails and using LM> NFS as storage. As of [2] it looks like this problem is known for a LM> while. On a normal NFS mount this does not happen as "silly renaming" LM> [1] works there (producing nasty little .nfsXXXX files). nfs_sillyrename() is called when vnode's usecount is more then 1. It is expected that unlink() syscall increases vnode's usecount in namei() and if the file has been already opened usecount will be more then 1. But with nullfs layer present the reference counts are held by the upper no= de, not the lower (nfs) one, so when unlink() is called it increases usecount of the upper vnode, not nfs vnode and nfs_sillyrename() is never called. The strightforward solution looks like to implement null_remove() that will increase lower vnode's refcount before calling null_bypass() and then decrement it after the call. See the attached patch (it works for me on both 8-STABLE and CURRENT). --=20 Mikolaj Golub