From owner-freebsd-fs@FreeBSD.ORG Fri Jun 14 19:01:24 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56110E25; Fri, 14 Jun 2013 19:01:24 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 24AD812B2; Fri, 14 Jun 2013 19:01:23 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r5EJ1Ej6015037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Jun 2013 14:01:16 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Fri, 14 Jun 2013 14:01:11 -0500 From: "Teske, Devin" To: Kirk McKusick Subject: Re: ZFS Union Thread-Topic: ZFS Union Thread-Index: AQHOaTA7lOdSGgtNJkChFq/RufGZx5k15IEA Date: Fri, 14 Jun 2013 19:01:11 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F81A60@ltcfiswmsgmb21> References: <201306141851.r5EIpkl2054401@chez.mckusick.com> In-Reply-To: <201306141851.r5EIpkl2054401@chez.mckusick.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-14_07:2013-06-14,2013-06-14,1970-01-01 signatures=0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-fs@freebsd.org" , Devin Teske X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:01:24 -0000 On Jun 14, 2013, at 11:51 AM, Kirk McKusick wrote: The union filesystem uses "whiteout" to remove files that appear in a lower layer. In your example, when you `rm /vm/unit1/foo' what happens is that a whiteout entry gets created for /vm/unit1/foo. (Whiteout is implemented by creating a name with inode number 1; Inode 1 is the "anti-inode" which when combined with any other inode disappears in a cloud of greasy smoke.) WINO=85 yes=85 just as your response came in, I was finding the code=85 http://svnweb.freebsd.org/base/head/sys/ufs/ufs/ufs_lookup.c?r1=3D156418&r2= =3D160269 if (ep->d_ino =3D=3D 0 || - (ep->d_ino =3D=3D WINO && + (ep->d_ino =3D=3D WINO && namlen =3D=3D dirp->d_namlen && bcmp(ep->d_name, dirp->d_name, dirp->d_namlen) =3D=3D 0)) { Thus /vm/master/foo continues to exist and is visible as /vm/unit2/foo and /vm/unit3/foo. You can "recover" /vm/unit1/foo using `rm -W /vm/unit1/foo' which will remove the whiteout entry causing /vm/master/foo to once again be visible as /vm/unit1/foo. Beautiful=85 that was my next consternation after seeing that it was in the= filesystem layer (how to reset the value from WINO to something that will = allow the lower layer to bleed through). In short, I believe that the existing union filesystem will do what you want to do. Kirk McKusick Absolutely right=85 thank you much Sir! I didn't know about "rm -W" until today. -- Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.