From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 18:06:58 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2B516A4CE; Sun, 3 Oct 2004 18:06:58 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31EF43D2D; Sun, 3 Oct 2004 18:06:57 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i93I5JNZ009076; Mon, 4 Oct 2004 03:05:20 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410031805.i93I5JNZ009076@sana.init-main.com> To: Uwe Doering In-reply-to: Your message of "Sun, 03 Oct 2004 17:33:52 +0200." <41601BE0.4050401@geminix.org> Date: Mon, 04 Oct 2004 03:05:19 +0900 From: Takanori Watanabe cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 18:06:58 -0000 In message <41601BE0.4050401@geminix.org>, Uwe Doering さんいわく: >takawata@jp.freebsd.org wrote: >> In message <415FC1A1.3020502@geminix.org>, Uwe Doering wrote: >> >>>Hi there, >>> >>>with regard to your above mentioned fix you may be interested in reading >>>this short discussion, especially my answer to the original article: >>> >>>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116615+0+archive/2004/freebsd-s >table/20040613.freebsd-stable >> >> Thank you for your comment. >> >> The code is what nullfs do. >> >> static int >> null_getattr(ap) >> struct vop_getattr_args /* { >> struct vnode *a_vp; >> struct vattr *a_vap; >> struct ucred *a_cred; >> struct thread *a_td; >> } */ *ap; >> { >> int error; >> >> if ((error = null_bypass((struct vop_generic_args *)ap)) != 0) >> return (error); >> >> ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; >> return (0); >> } >> >> I'm pleased if you explain why it is done >> for nullfs and not for unionfs, if any. >> IMHO, there are not so much advantage in assuming >> exactly same file exists in different filesystem, >> if the entity is same. > >'nullfs' has only one underlying file system, so replacing the file >system id doesn't break the uniqueness of the va_fsid/va_fileid pair. >The latter is the inode number in case of UFS. > >With 'unionfs' you can have underlying files from two different layers >(upper and lower) on two different file systems which may, by >coincidence, have the same inode number. Now, if you override the real >va_fsid with that of the 'unionfs' mount you'll end up with two >'unionfs' vnodes that appear to represent the same file (a hard link, >for instance), but in reality the files are different entities. >Obviously, both the kernel and applications might draw wrong conclusions >in this case. I think the three filesystem entry 1. upper layer file 2. lower layer file 3. unionfs file can be treated as different. >> But I want to hear from FS gurus. >> I found that I reverted the change at CVS rev 1.62. >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/unionfs/union_vnops.c.diff? >r1=1.61&r2=1.62 > >Right. Better safe than sorry. Same change are applyed in nullfs and reverted by bp@. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/null_vnops.c.diff?r1=1.33&r2=1.34 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nullfs/null_vnops.c.diff?r1=1.40&r2=1.41 From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 18:32:26 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF61516A4CE; Sun, 3 Oct 2004 18:32:26 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0624943D1D; Sun, 3 Oct 2004 18:32:26 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i93IWbYw008147; Sun, 3 Oct 2004 14:32:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93IWbHU008146; Sun, 3 Oct 2004 14:32:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 14:32:37 -0400 From: David Schultz To: Takanori Watanabe Message-ID: <20041003183237.GA8100@VARK.MIT.EDU> Mail-Followup-To: Takanori Watanabe , Uwe Doering , freebsd-fs@FreeBSD.ORG, bp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410031805.i93I5JNZ009076@sana.init-main.com> cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Uwe Doering Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 18:32:27 -0000 On Mon, Oct 04, 2004, Takanori Watanabe wrote: > >With 'unionfs' you can have underlying files from two different layers > >(upper and lower) on two different file systems which may, by > >coincidence, have the same inode number. Now, if you override the real > >va_fsid with that of the 'unionfs' mount you'll end up with two > >'unionfs' vnodes that appear to represent the same file (a hard link, > >for instance), but in reality the files are different entities. > >Obviously, both the kernel and applications might draw wrong conclusions > >in this case. > > I think the three filesystem entry > 1. upper layer file > 2. lower layer file > 3. unionfs file > can be treated as different. I didn't pursue this before because I was concerned that it would introduce cache consistency issues between the union vnode and the underlying vnode. But I guess all vnops ultimately wind up at the underlying vnode, so this hopefully isn't an issue... From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 19:42:29 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED66816A4CE; Sun, 3 Oct 2004 19:42:29 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54A5043D54; Sun, 3 Oct 2004 19:42:29 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <41605620.90407@geminix.org> Date: Sun, 03 Oct 2004 21:42:24 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> In-Reply-To: <20041003183237.GA8100@VARK.MIT.EDU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207000702050607060306" Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CECFX-0008J5-00; Sun, 03 Oct 2004 21:42:28 +0200 cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 19:42:30 -0000 This is a cryptographically signed message in MIME format. --------------ms030207000702050607060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Schultz wrote: > On Mon, Oct 04, 2004, Takanori Watanabe wrote: > >>>With 'unionfs' you can have underlying files from two different layers >>>(upper and lower) on two different file systems which may, by >>>coincidence, have the same inode number. Now, if you override the real >>>va_fsid with that of the 'unionfs' mount you'll end up with two >>>'unionfs' vnodes that appear to represent the same file (a hard link, >>>for instance), but in reality the files are different entities. >>>Obviously, both the kernel and applications might draw wrong conclusions >>>in this case. >> >>I think the three filesystem entry >>1. upper layer file >>2. lower layer file >>3. unionfs file >>can be treated as different. > > I didn't pursue this before because I was concerned that it would > introduce cache consistency issues between the union vnode and the > underlying vnode. But I guess all vnops ultimately wind up at the > underlying vnode, so this hopefully isn't an issue... Applications use the synthesized unionfs vnodes. They have no knowledge of what's going on underneath. So they can't tell whether one unionfs vnode refers to a file in the upper layer, and the other to one in the lower layer. In case of a stat(2), for instance, if va_fsid is to be overridden by the va_fsid of the unionfs' mount, unionfs would need to generate and manage its own (unique) file numbers as well, instead of passing va_fileid of the underlying layer unchanged. Otherwise you get the ambiguity I pointed out. Uwe -- Uwe Doering gemini@geminix.org --------------ms030207000702050607060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHrjCC A9MwggM8oAMCAQICDmNUAAAAAoJXW0abG14gMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQG EwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMg VHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UE CxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNh dGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDQwNDI4MTIxODM5WhcNMDUwNDI4MTIxODM5WjBGMQsw CQYDVQQGEwJERTEUMBIGA1UEAxMLVXdlIERvZXJpbmcxITAfBgkqhkiG9w0BCQEWEmdlbWlu aUBnZW1pbml4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2v0dloMDr/ lryhtRYHqKz9SsOUbXjUx7WVDPOKnDXkkAS8KYmgxvgWyeSoCHLSA8RIzejUwu/djAyI0z4U jRsZQYC/8qEnoDaZ+mawWNtib3MH+kxgDM1ZQpKuyvXFrob39zr4/CwK8rWPX//dTvrhgba8 svvviFSyC8/dDqMJzdYX78Z2ubrXgMsUbKLV9Ruw38z925nv6/dZx8HdpcdvVpQ2WHyBXlOA p8XxeB4jqU4Hr+g+fGAf2Un2PCLkAyPS1ZXIMfvJ3O4eyXg7bBVi3TRpdjp4FOw4BvYWfKda cPC/zS5IIlxR7LItPslm08iOUzb5+r4CcvYI1r1NVQMCAwEAAaOByDCBxTAMBgNVHRMBAf8E AjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZO aHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzYzNTQw MDAwMDAwMjgyNTc1QjQ2OUIxQjVFMjA/MA0GCSqGSIb3DQEBBAUAA4GBAEOLk5EYoZXWBr+8 as3IXYuobmSfZOCzKC1fFZd0G+Ok2kB/ctYzWhZQYjrNytjQIICscEKywFKRWEBh9DhbKOgc XheFRl3qNIeYCcruZjLnKMIcFGFoMs6dlfXnW+kDWIvshzGcFRbXv9Npce9Hn1jPIR7xrua+ ZplRab2xddtDMIID0zCCAzygAwIBAgIOY1QAAAACgldbRpsbXiAwDQYJKoZIhvcNAQEEBQAw gbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTow OAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBH bWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw0wNDA0MjgxMjE4MzlaFw0wNTA0Mjgx MjE4MzlaMEYxCzAJBgNVBAYTAkRFMRQwEgYDVQQDEwtVd2UgRG9lcmluZzEhMB8GCSqGSIb3 DQEJARYSZ2VtaW5pQGdlbWluaXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAva/R2WgwOv+WvKG1FgeorP1Kw5RteNTHtZUM84qcNeSQBLwpiaDG+BbJ5KgIctIDxEjN 6NTC792MDIjTPhSNGxlBgL/yoSegNpn6ZrBY22Jvcwf6TGAMzVlCkq7K9cWuhvf3Ovj8LAry tY9f/91O+uGBtryy+++IVLILz90OownN1hfvxna5uteAyxRsotX1G7DfzP3bme/r91nHwd2l x29WlDZYfIFeU4CnxfF4HiOpTgev6D58YB/ZSfY8IuQDI9LVlcgx+8nc7h7JeDtsFWLdNGl2 OngU7DgG9hZ8p1pw8L/NLkgiXFHssi0+yWbTyI5TNvn6vgJy9gjWvU1VAwIDAQABo4HIMIHF MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMDMGCWCGSAGG+EIBCAQmFiRodHRwOi8v d3d3LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwEQYJYIZIAYb4QgEBBAQDAgWgMF0GCWCG SAGG+EIBAwRQFk5odHRwczovL3d3dy50cnVzdGNlbnRlci5kZS9jZ2ktYmluL2NoZWNrLXJl di5jZ2kvNjM1NDAwMDAwMDAyODI1NzVCNDY5QjFCNUUyMD8wDQYJKoZIhvcNAQEEBQADgYEA Q4uTkRihldYGv7xqzchdi6huZJ9k4LMoLV8Vl3Qb46TaQH9y1jNaFlBiOs3K2NAggKxwQrLA UpFYQGH0OFso6BxeF4VGXeo0h5gJyu5mMucowhwUYWgyzp2V9edb6QNYi+yHMZwVFte/02lx 70efWM8hHvGu5r5mmVFpvbF120MxggR0MIIEcAIBATCBzzCBvDELMAkGA1UEBhMCREUxEDAO BgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRy dXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0 Y2VudGVyLmRlAg5jVAAAAAKCV1tGmxteIDAJBgUrDgMCGgUAoIICeTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMDMxOTQyMjRaMCMGCSqGSIb3DQEJ BDEWBBQvNHPNl7rYSOfMmMAICn5iUWqsADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB4AYJKwYBBAGCNxAEMYHSMIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVy ZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3Vy aXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDmNU AAAAAoJXW0abG14gMIHiBgsqhkiG9w0BCRACCzGB0qCBzzCBvDELMAkGA1UEBhMCREUxEDAO BgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2Vu dGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRy dXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0 Y2VudGVyLmRlAg5jVAAAAAKCV1tGmxteIDANBgkqhkiG9w0BAQEFAASCAQAl8LuqkrFmjYEr QuQUVSET1aJ5PlDWrWI8dNdKVuvQ4E/+mD592d/+2YfRWqzx7Cw1u6m+S05/5SDk4+9RMpD0 2T2vf+Z3mtMPRbTIQAHAm78S3hr23PqHhZgOscfs5zaYkffyF3F36my16SbQGkWe6ZGdNJ7H S2P60a/KDT5aMzj7eTaG4W0cAalSW8Lh6FUDy+Lnj0GpMh9QbEyXWjUzT+EgQRdOtK1E2UVa xtP3HSHLniE9avxmByX+ESj7fQlAludhKVgqNAWnPXrSwkYX6seuWdp32tv5/gvIlHpV/qsk 1Lfq2bVmXB/A2izFmG9lKXPl64mg2QdkW9sbvjc8AAAAAAAA --------------ms030207000702050607060306-- From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 20:07:52 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 001FE16A4CE; Sun, 3 Oct 2004 20:07:51 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9713D43D1D; Sun, 3 Oct 2004 20:07:51 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i93K832c008713; Sun, 3 Oct 2004 16:08:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93K83cl008712; Sun, 3 Oct 2004 16:08:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 16:08:03 -0400 From: David Schultz To: Uwe Doering Message-ID: <20041003200803.GA8668@VARK.MIT.EDU> Mail-Followup-To: Uwe Doering , Takanori Watanabe , freebsd-fs@FreeBSD.ORG, bp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41605620.90407@geminix.org> cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 20:07:52 -0000 On Sun, Oct 03, 2004, Uwe Doering wrote: > >>I think the three filesystem entry > >>1. upper layer file > >>2. lower layer file > >>3. unionfs file > >>can be treated as different. > > > >I didn't pursue this before because I was concerned that it would > >introduce cache consistency issues between the union vnode and the > >underlying vnode. But I guess all vnops ultimately wind up at the > >underlying vnode, so this hopefully isn't an issue... > > Applications use the synthesized unionfs vnodes. They have no knowledge > of what's going on underneath. So they can't tell whether one unionfs > vnode refers to a file in the upper layer, and the other to one in the > lower layer. That isn't the issue. The issue is that an application might open the vnode in the unionfs mount, and another application might modify the same file in the underlying file system. If the kernel doesn't understand that it is really the same file, then cache incoherencies will occur. I'm actually not sure to what extent this is a problem already; John Heidemann's Phd thesis had a way of dealing with it, but FreeBSD doesn't do things that way AFAIK. From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 21:01:45 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC07316A4CE; Sun, 3 Oct 2004 21:01:45 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B1CE43D2D; Sun, 3 Oct 2004 21:01:45 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i93L1vFc009209; Sun, 3 Oct 2004 17:01:57 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i93L1uLD009208; Sun, 3 Oct 2004 17:01:56 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 3 Oct 2004 17:01:56 -0400 From: David Schultz To: Uwe Doering Message-ID: <20041003210156.GA9127@VARK.MIT.EDU> Mail-Followup-To: Uwe Doering , Takanori Watanabe , freebsd-fs@FreeBSD.ORG, bp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41605620.90407@geminix.org> cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 21:01:46 -0000 On Sun, Oct 03, 2004, Uwe Doering wrote: > David Schultz wrote: > >On Mon, Oct 04, 2004, Takanori Watanabe wrote: > > > >>>With 'unionfs' you can have underlying files from two different layers > >>>(upper and lower) on two different file systems which may, by > >>>coincidence, have the same inode number. Now, if you override the real > >>>va_fsid with that of the 'unionfs' mount you'll end up with two > >>>'unionfs' vnodes that appear to represent the same file (a hard link, > >>>for instance), but in reality the files are different entities. > >>>Obviously, both the kernel and applications might draw wrong conclusions > >>>in this case. > >> > >>I think the three filesystem entry > >>1. upper layer file > >>2. lower layer file > >>3. unionfs file > >>can be treated as different. > > > >I didn't pursue this before because I was concerned that it would > >introduce cache consistency issues between the union vnode and the > >underlying vnode. But I guess all vnops ultimately wind up at the > >underlying vnode, so this hopefully isn't an issue... > > Applications use the synthesized unionfs vnodes. They have no knowledge > of what's going on underneath. So they can't tell whether one unionfs > vnode refers to a file in the upper layer, and the other to one in the > lower layer. In my previous message I was confusing two issues, so please allow me to clarify. One issue is that NFS uses the fsid to look up vnodes, so it isn't clear to me what effect this change might have over NFS-exported unionfs mounts. (A while ago they didn't work anyway, but I thought that was fixed.) The other issue is cache coherency between the upper and lower vnodes, which I think unionfs gets wrong when mmap() is involved---I think it needs its own (get|put)pages() that proxy the request to the correct layer. From owner-freebsd-fs@FreeBSD.ORG Sun Oct 3 21:06:46 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E116A4CE; Sun, 3 Oct 2004 21:06:46 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9C9A43D3F; Sun, 3 Oct 2004 21:06:45 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <416069E2.6030403@geminix.org> Date: Sun, 03 Oct 2004 23:06:42 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> <20041003200803.GA8668@VARK.MIT.EDU> In-Reply-To: <20041003200803.GA8668@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CEDZ6-000A5x-00; Sun, 03 Oct 2004 23:06:45 +0200 cc: freebsd-fs@FreeBSD.ORG cc: bp@FreeBSD.ORG cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2004 21:06:46 -0000 David Schultz wrote: > On Sun, Oct 03, 2004, Uwe Doering wrote: > >>>>I think the three filesystem entry >>>>1. upper layer file >>>>2. lower layer file >>>>3. unionfs file >>>>can be treated as different. >>> >>>I didn't pursue this before because I was concerned that it would >>>introduce cache consistency issues between the union vnode and the >>>underlying vnode. But I guess all vnops ultimately wind up at the >>>underlying vnode, so this hopefully isn't an issue... >> >>Applications use the synthesized unionfs vnodes. They have no knowledge >>of what's going on underneath. So they can't tell whether one unionfs >>vnode refers to a file in the upper layer, and the other to one in the >>lower layer. > > That isn't the issue. The issue is that an application might open > the vnode in the unionfs mount, and another application might > modify the same file in the underlying file system. If the kernel > doesn't understand that it is really the same file, then cache > incoherencies will occur. I'm actually not sure to what extent > this is a problem already; John Heidemann's Phd thesis had a way > of dealing with it, but FreeBSD doesn't do things that way AFAIK. Okay, but that's a different matter. What I was addressing at the start of this discussion is an ambiguity issue with meta data, that is, information that ends up in stat(2) and friends. As to your concern, in CURRENT this might be fixed already. There, the unionfs vnode doesn't have an object attached. Instead, calls to VOP_GETVOBJECT() get forwarded to the underlying file, so the same object gets referred as for direct modifications of that file. That should rule out any coherency problems, IMHO. Unfortunately, AFAIK, this fix has never been MFC'ed to 4-STABLE. The respective CVS commits are union_subr.c (rev. 1.51) and union_vnops.c (rev. 1.82). Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 05:31:12 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F075F16A4CE; Mon, 4 Oct 2004 05:31:12 +0000 (GMT) Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0880243D2F; Mon, 4 Oct 2004 05:31:11 +0000 (GMT) (envelope-from bp@butya.kz) Received: from lion.butya.kz (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with SMTP id A06715C9F; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Received: from relay.butya.kz (localhost [127.0.0.1]) by localhost.butya.kz (Postfix) with ESMTP id 79AEC5C9D; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Received: by relay.butya.kz (Postfix, from userid 1000) id 745055C84; Mon, 4 Oct 2004 12:31:06 +0700 (ALMST) Date: Mon, 4 Oct 2004 12:31:06 +0700 From: Boris Popov To: Uwe Doering Message-ID: <20041004053106.GQ88303@vertex.kz> References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> <20041003200803.GA8668@VARK.MIT.EDU> <416069E2.6030403@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416069E2.6030403@geminix.org> User-Agent: Mutt/1.5.6i cc: freebsd-fs@FreeBSD.ORG cc: David Schultz cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 05:31:13 -0000 On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: > > > >That isn't the issue. The issue is that an application might open > >the vnode in the unionfs mount, and another application might > >modify the same file in the underlying file system. If the kernel > >doesn't understand that it is really the same file, then cache > >incoherencies will occur. I'm actually not sure to what extent > >this is a problem already; John Heidemann's Phd thesis had a way > >of dealing with it, but FreeBSD doesn't do things that way AFAIK. > > Okay, but that's a different matter. What I was addressing at the start > of this discussion is an ambiguity issue with meta data, that is, > information that ends up in stat(2) and friends. Exactly, one never knows what parts of metadata used by applications. I can confirm that ino are ought to be unique inside filesystem, otherwise some programs will fail in a very obscure ways. > > As to your concern, in CURRENT this might be fixed already. There, the > unionfs vnode doesn't have an object attached. Instead, calls to > VOP_GETVOBJECT() get forwarded to the underlying file, so the same > object gets referred as for direct modifications of that file. That > should rule out any coherency problems, IMHO. > > Unfortunately, AFAIK, this fix has never been MFC'ed to 4-STABLE. The > respective CVS commits are union_subr.c (rev. 1.51) and union_vnops.c > (rev. 1.82). Correct, VOP_*VOBJECT() vnops were introduced to fill the gap in absence of UBC and should solve most of the cache coherency problems when used properly. -- Boris Popov http://rbp.euro.ru From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 06:08:14 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 532CE16A4CE; Mon, 4 Oct 2004 06:08:14 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7422C43D1F; Mon, 4 Oct 2004 06:08:13 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i9466UVm012207; Mon, 4 Oct 2004 15:06:31 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410040606.i9466UVm012207@sana.init-main.com> To: Boris Popov In-reply-to: Your message of "Mon, 04 Oct 2004 12:31:06 +0700." <20041004053106.GQ88303@vertex.kz> Date: Mon, 04 Oct 2004 15:06:30 +0900 From: Takanori Watanabe cc: freebsd-fs@FreeBSD.org cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: gemini@geminix.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 06:08:14 -0000 In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: >On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >> > >> >That isn't the issue. The issue is that an application might open >> >the vnode in the unionfs mount, and another application might >> >modify the same file in the underlying file system. If the kernel >> >doesn't understand that it is really the same file, then cache >> >incoherencies will occur. I'm actually not sure to what extent >> >this is a problem already; John Heidemann's Phd thesis had a way >> >of dealing with it, but FreeBSD doesn't do things that way AFAIK. >> >> Okay, but that's a different matter. What I was addressing at the start >> of this discussion is an ambiguity issue with meta data, that is, >> information that ends up in stat(2) and friends. > > Exactly, one never knows what parts of metadata used by applications. >I can confirm that ino are ought to be unique inside filesystem, otherwise >some programs will fail in a very obscure ways. Ok, the issue Uwe says is when underlying filesystem and wrapping filesystem are diffent and if there are two files with same identifier exists. And the issue I want to fix is when underlying filesystem and wrapping filesystem are same so getcwd routine failed to distinguish the mount point. So it can be solved by translating fsid if the fsid of a file is same as that of mountpoint. True? From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 06:18:20 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 267FE16A4CE; Mon, 4 Oct 2004 06:18:20 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6D143D1D; Mon, 4 Oct 2004 06:18:19 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i946IToh011539; Mon, 4 Oct 2004 02:18:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i946ITp7011538; Mon, 4 Oct 2004 02:18:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 4 Oct 2004 02:18:29 -0400 From: David Schultz To: Takanori Watanabe Message-ID: <20041004061829.GB11422@VARK.MIT.EDU> Mail-Followup-To: Takanori Watanabe , Boris Popov , gemini@geminix.org, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20041004053106.GQ88303@vertex.kz> <200410040606.i9466UVm012207@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410040606.i9466UVm012207@sana.init-main.com> cc: freebsd-fs@FreeBSD.ORG cc: Boris Popov cc: freebsd-current@FreeBSD.ORG cc: gemini@geminix.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 06:18:20 -0000 On Mon, Oct 04, 2004, Takanori Watanabe wrote: > In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: > >On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: > >> > > >> >That isn't the issue. The issue is that an application might open > >> >the vnode in the unionfs mount, and another application might > >> >modify the same file in the underlying file system. If the kernel > >> >doesn't understand that it is really the same file, then cache > >> >incoherencies will occur. I'm actually not sure to what extent > >> >this is a problem already; John Heidemann's Phd thesis had a way > >> >of dealing with it, but FreeBSD doesn't do things that way AFAIK. > >> > >> Okay, but that's a different matter. What I was addressing at the start > >> of this discussion is an ambiguity issue with meta data, that is, > >> information that ends up in stat(2) and friends. > > > > Exactly, one never knows what parts of metadata used by applications. > >I can confirm that ino are ought to be unique inside filesystem, otherwise > >some programs will fail in a very obscure ways. > > Ok, the issue Uwe says is when underlying filesystem and > wrapping filesystem are diffent and if there are two files > with same identifier exists. > And the issue I want to fix is when underlying filesystem and > wrapping filesystem are same so getcwd routine failed to distinguish > the mount point. > > So it can be solved by translating fsid if the fsid of a file is same as > that of mountpoint. True? Many applications use the file's inode number and the filesystem device number to uniquely identify files, since this information can be easily and portably extracted via stat(2). IIRC, unionfs has always used the upper layer's device number, which is arguably wrong. I think the main consumer of fsids is NFS, which uses fsids along with i-numbers to construct file handles. umount(..., MNT_BYFSID) is another interface that uses fsids. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 06:26:19 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C431416A4CF; Mon, 4 Oct 2004 06:26:19 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E31443D41; Mon, 4 Oct 2004 06:26:19 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <4160ED06.6070603@geminix.org> Date: Mon, 04 Oct 2004 08:26:14 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takanori Watanabe References: <200410040606.i9466UVm012207@sana.init-main.com> In-Reply-To: <200410040606.i9466UVm012207@sana.init-main.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CEMIa-000NRR-00; Mon, 04 Oct 2004 08:26:17 +0200 cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 06:26:20 -0000 Takanori Watanabe wrote: > In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: > >>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >> >>>>That isn't the issue. The issue is that an application might open >>>>the vnode in the unionfs mount, and another application might >>>>modify the same file in the underlying file system. If the kernel >>>>doesn't understand that it is really the same file, then cache >>>>incoherencies will occur. I'm actually not sure to what extent >>>>this is a problem already; John Heidemann's Phd thesis had a way >>>>of dealing with it, but FreeBSD doesn't do things that way AFAIK. >>> >>>Okay, but that's a different matter. What I was addressing at the start >>>of this discussion is an ambiguity issue with meta data, that is, >>>information that ends up in stat(2) and friends. >> >> Exactly, one never knows what parts of metadata used by applications. >>I can confirm that ino are ought to be unique inside filesystem, otherwise >>some programs will fail in a very obscure ways. > > Ok, the issue Uwe says is when underlying filesystem and > wrapping filesystem are diffent and if there are two files > with same identifier exists. > And the issue I want to fix is when underlying filesystem and > wrapping filesystem are same so getcwd routine failed to distinguish > the mount point. > > So it can be solved by translating fsid if the fsid of a file is same as > that of mountpoint. True? Correct. In this case the inode number is guaranteed to be unique. This might be okay as a local patch, but it is IMHO not a fix suited for FreeBSD in general. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 06:38:24 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 826E316A4CE; Mon, 4 Oct 2004 06:38:24 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A8F943D31; Mon, 4 Oct 2004 06:38:24 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <4160EFDC.90609@geminix.org> Date: Mon, 04 Oct 2004 08:38:20 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <20041004053106.GQ88303@vertex.kz> <200410040606.i9466UVm012207@sana.init-main.com> <20041004061829.GB11422@VARK.MIT.EDU> In-Reply-To: <20041004061829.GB11422@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CEMUJ-000NfK-00; Mon, 04 Oct 2004 08:38:23 +0200 cc: freebsd-fs@FreeBSD.ORG cc: Boris Popov cc: Takanori Watanabe cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 06:38:24 -0000 David Schultz wrote: > On Mon, Oct 04, 2004, Takanori Watanabe wrote: > >>In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: >> >>>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >>> >>>>>That isn't the issue. The issue is that an application might open >>>>>the vnode in the unionfs mount, and another application might >>>>>modify the same file in the underlying file system. If the kernel >>>>>doesn't understand that it is really the same file, then cache >>>>>incoherencies will occur. I'm actually not sure to what extent >>>>>this is a problem already; John Heidemann's Phd thesis had a way >>>>>of dealing with it, but FreeBSD doesn't do things that way AFAIK. >>>> >>>>Okay, but that's a different matter. What I was addressing at the start >>>>of this discussion is an ambiguity issue with meta data, that is, >>>>information that ends up in stat(2) and friends. >>> >>> Exactly, one never knows what parts of metadata used by applications. >>>I can confirm that ino are ought to be unique inside filesystem, otherwise >>>some programs will fail in a very obscure ways. >> >>Ok, the issue Uwe says is when underlying filesystem and >>wrapping filesystem are diffent and if there are two files >>with same identifier exists. >>And the issue I want to fix is when underlying filesystem and >>wrapping filesystem are same so getcwd routine failed to distinguish >>the mount point. >> >>So it can be solved by translating fsid if the fsid of a file is same as >>that of mountpoint. True? > > Many applications use the file's inode number and the filesystem > device number to uniquely identify files, since this information > can be easily and portably extracted via stat(2). IIRC, unionfs > has always used the upper layer's device number, which is arguably > wrong. Not exactly. If the underlying file is in the upper layer, the va_fsid/va_fileid fields of the upper layer are returned. If the file resides in the lower layer, va_fsid/va_fileid come from that layer. If there is a file in both the upper and lower layer, the upper layer's meta data is returned. Which is correct as well because in this case the file in the lower layer is completely ignored as far as data retrieval and modification are concerned. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 07:07:29 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2B7716A4CE; Mon, 4 Oct 2004 07:07:28 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE5D943D45; Mon, 4 Oct 2004 07:07:27 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i9475jwq012503; Mon, 4 Oct 2004 16:05:45 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410040705.i9475jwq012503@sana.init-main.com> To: Uwe Doering From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 04 Oct 2004 08:26:14 +0200." <4160ED06.6070603@geminix.org> Date: Mon, 04 Oct 2004 16:05:45 +0900 Sender: takawata@init-main.com cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 07:07:29 -0000 In message <4160ED06.6070603@geminix.org>, Uwe Doering wrote: >Takanori Watanabe wrote: >> In message <20041004053106.GQ88303@vertex.kz>, Boris Popov wrote: >> >>>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >>> >>>>>That isn't the issue. The issue is that an application might open >>>>>the vnode in the unionfs mount, and another application might >>>>>modify the same file in the underlying file system. If the kernel >>>>>doesn't understand that it is really the same file, then cache >>>>>incoherencies will occur. I'm actually not sure to what extent >>>>>this is a problem already; John Heidemann's Phd thesis had a way >>>>>of dealing with it, but FreeBSD doesn't do things that way AFAIK. >>>> >>>>Okay, but that's a different matter. What I was addressing at the start >>>>of this discussion is an ambiguity issue with meta data, that is, >>>>information that ends up in stat(2) and friends. >>> >>> Exactly, one never knows what parts of metadata used by applications. >>>I can confirm that ino are ought to be unique inside filesystem, otherwise >>>some programs will fail in a very obscure ways. >> >> Ok, the issue Uwe says is when underlying filesystem and >> wrapping filesystem are diffent and if there are two files >> with same identifier exists. >> And the issue I want to fix is when underlying filesystem and >> wrapping filesystem are same so getcwd routine failed to distinguish >> the mount point. >> >> So it can be solved by translating fsid if the fsid of a file is same as >> that of mountpoint. True? > >Correct. In this case the inode number is guaranteed to be unique. >This might be okay as a local patch, but it is IMHO not a fix suited for >FreeBSD in general. Ok. How about this? Index: union_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union_vnops.c,v retrieving revision 1.109 diff -u -r1.109 union_vnops.c --- union_vnops.c 2 Oct 2004 17:17:04 -0000 1.109 +++ union_vnops.c 4 Oct 2004 07:04:38 -0000 @@ -951,6 +951,8 @@ error = VOP_GETATTR(vp, vap, ap->a_cred, ap->a_td); if (error) return (error); + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; + /* XXX isn't this dangerous without a lock? */ union_newsize(ap->a_vp, vap->va_size, VNOVAL); } @@ -972,7 +974,6 @@ union_newsize(ap->a_vp, VNOVAL, vap->va_size); } - ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; if ((vap != ap->a_vap) && (vap->va_type == VDIR)) ap->a_vap->va_nlink += vap->va_nlink; From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 07:29:41 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1005816A4CE; Mon, 4 Oct 2004 07:29:41 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00CA43D39; Mon, 4 Oct 2004 07:29:40 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <4160FBD9.10603@geminix.org> Date: Mon, 04 Oct 2004 09:29:29 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: takawata@jp.freebsd.org References: <200410040705.i9475jwq012503@sana.init-main.com> In-Reply-To: <200410040705.i9475jwq012503@sana.init-main.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CENHn-000OjA-00; Mon, 04 Oct 2004 09:29:32 +0200 cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 07:29:41 -0000 takawata@jp.freebsd.org wrote: > In message <4160ED06.6070603@geminix.org>, Uwe Doering wrote: > >>Takanori Watanabe wrote: >>[...] >>>Ok, the issue Uwe says is when underlying filesystem and >>>wrapping filesystem are diffent and if there are two files >>>with same identifier exists. >>>And the issue I want to fix is when underlying filesystem and >>>wrapping filesystem are same so getcwd routine failed to distinguish >>>the mount point. >>> >>>So it can be solved by translating fsid if the fsid of a file is same as >>>that of mountpoint. True? >> >>Correct. In this case the inode number is guaranteed to be unique. >>This might be okay as a local patch, but it is IMHO not a fix suited for >>FreeBSD in general. > > Ok. How about this? > > Index: union_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/unionfs/union_vnops.c,v > retrieving revision 1.109 > diff -u -r1.109 union_vnops.c > --- union_vnops.c 2 Oct 2004 17:17:04 -0000 1.109 > +++ union_vnops.c 4 Oct 2004 07:04:38 -0000 > @@ -951,6 +951,8 @@ > error = VOP_GETATTR(vp, vap, ap->a_cred, ap->a_td); > if (error) > return (error); > + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; > + > /* XXX isn't this dangerous without a lock? */ > union_newsize(ap->a_vp, vap->va_size, VNOVAL); > } > @@ -972,7 +974,6 @@ > union_newsize(ap->a_vp, VNOVAL, vap->va_size); > } > > - ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; > > if ((vap != ap->a_vap) && (vap->va_type == VDIR)) > ap->a_vap->va_nlink += vap->va_nlink; This wouldn't be correct, either. Unionfs can be stacked, that is, you can't even be sure for a single layer that the passed up va_fsid will always be the same. The underlying unionfs can be comprised of two layers on two different file systems as well, and so on. You can override va_fsid only if the original file system id is guaranteed to be the same for all files in that layer (single file system case). Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 07:50:57 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B56316A4CE; Mon, 4 Oct 2004 07:50:57 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 239A843D5D; Mon, 4 Oct 2004 07:50:57 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <416100D9.10809@geminix.org> Date: Mon, 04 Oct 2004 09:50:49 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: takawata@jp.freebsd.org References: <200410040705.i9475jwq012503@sana.init-main.com> <4160FBD9.10603@geminix.org> In-Reply-To: <4160FBD9.10603@geminix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CENcR-000PA7-00; Mon, 04 Oct 2004 09:50:52 +0200 cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 07:50:57 -0000 Uwe Doering wrote: > takawata@jp.freebsd.org wrote: >> >>[...] >> Ok. How about this? >> >> Index: union_vnops.c >> =================================================================== >> RCS file: /home/ncvs/src/sys/fs/unionfs/union_vnops.c,v >> retrieving revision 1.109 >> diff -u -r1.109 union_vnops.c >> --- union_vnops.c 2 Oct 2004 17:17:04 -0000 1.109 >> +++ union_vnops.c 4 Oct 2004 07:04:38 -0000 >> @@ -951,6 +951,8 @@ >> error = VOP_GETATTR(vp, vap, ap->a_cred, ap->a_td); >> if (error) >> return (error); >> + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; >> + >> /* XXX isn't this dangerous without a lock? */ >> union_newsize(ap->a_vp, vap->va_size, VNOVAL); >> } >> @@ -972,7 +974,6 @@ >> union_newsize(ap->a_vp, VNOVAL, vap->va_size); >> } >> >> - ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; >> >> if ((vap != ap->a_vap) && (vap->va_type == VDIR)) >> ap->a_vap->va_nlink += vap->va_nlink; > > This wouldn't be correct, either. Unionfs can be stacked, that is, you > can't even be sure for a single layer that the passed up va_fsid will > always be the same. The underlying unionfs can be comprised of two > layers on two different file systems as well, and so on. You can > override va_fsid only if the original file system id is guaranteed to be > the same for all files in that layer (single file system case). Since you mentioned nullfs earlier on, it just occured to me that overriding va_fsid in nullfs is wrong, too. You can have a nullfs mount with an underlying unionfs, so the passed up va_fsid isn't guaranteed to be the same in this case, either, and therefore must not be overridden. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 09:13:59 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6497816A4CF; Mon, 4 Oct 2004 09:13:59 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3CF243D45; Mon, 4 Oct 2004 09:13:58 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost.init-main.com [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i949CEjk012965; Mon, 4 Oct 2004 18:12:14 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200410040912.i949CEjk012965@sana.init-main.com> To: Uwe Doering In-reply-to: Your message of "Mon, 04 Oct 2004 09:29:29 +0200." <4160FBD9.10603@geminix.org> Date: Mon, 04 Oct 2004 18:12:14 +0900 From: Takanori Watanabe cc: freebsd-fs@FreeBSD.org cc: Boris Popov cc: das@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 09:13:59 -0000 In message <4160FBD9.10603@geminix.org>, Uwe Doering wrote: >takawata@jp.freebsd.org wrote: >> In message <4160ED06.6070603@geminix.org>, Uwe Doering wrote: >> >>>Takanori Watanabe wrote: >>>[...] >>>>Ok, the issue Uwe says is when underlying filesystem and >>>>wrapping filesystem are diffent and if there are two files >>>>with same identifier exists. >>>>And the issue I want to fix is when underlying filesystem and >>>>wrapping filesystem are same so getcwd routine failed to distinguish >>>>the mount point. >>>> >>>>So it can be solved by translating fsid if the fsid of a file is same as >>>>that of mountpoint. True? >>> >>>Correct. In this case the inode number is guaranteed to be unique. >>>This might be okay as a local patch, but it is IMHO not a fix suited for >>>FreeBSD in general. >> >> Ok. How about this? > >This wouldn't be correct, either. Unionfs can be stacked, that is, you >can't even be sure for a single layer that the passed up va_fsid will >always be the same. The underlying unionfs can be comprised of two >layers on two different file systems as well, and so on. You can >override va_fsid only if the original file system id is guaranteed to be >the same for all files in that layer (single file system case). Ok, whats next? Index: union.h =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union.h,v retrieving revision 1.28 diff -u -r1.28 union.h --- union.h 7 Apr 2004 20:46:03 -0000 1.28 +++ union.h 4 Oct 2004 09:03:26 -0000 @@ -44,6 +44,7 @@ struct ucred *um_cred; /* Credentials of user calling mount */ int um_cmode; /* cmask from mount process */ int um_op; /* Operation mode */ + dev_t um_upperdev; /* Upper root node fsid[0]*/ }; #ifdef _KERNEL Index: union_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union_vfsops.c,v retrieving revision 1.67 diff -u -r1.67 union_vfsops.c --- union_vfsops.c 30 Jul 2004 22:08:51 -0000 1.67 +++ union_vfsops.c 4 Oct 2004 09:03:26 -0000 @@ -72,6 +72,7 @@ struct vnode *lowerrootvp = NULLVP; struct vnode *upperrootvp = NULLVP; struct union_mount *um = 0; + struct vattr va; struct ucred *cred = 0; char *cp = 0, *target; int op; @@ -190,6 +191,12 @@ M_UNIONFSMNT, M_WAITOK | M_ZERO); um->um_op = op; + + error = VOP_GETATTR(upperrootvp, &va, td->td_ucred, td); + if(error) + goto bad; + + um->um_upperdev = va.va_fsid; switch (um->um_op) { case UNMNT_ABOVE: Index: union_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/unionfs/union_vnops.c,v retrieving revision 1.109 diff -u -r1.109 union_vnops.c --- union_vnops.c 2 Oct 2004 17:17:04 -0000 1.109 +++ union_vnops.c 4 Oct 2004 09:03:27 -0000 @@ -932,6 +932,7 @@ { int error; struct union_node *un = VTOUNION(ap->a_vp); + struct union_mount *um = MOUNTTOUNIONMOUNT(ap->a_vp->v_mount); struct vnode *vp; struct vattr *vap; struct vattr va; @@ -972,7 +973,8 @@ union_newsize(ap->a_vp, VNOVAL, vap->va_size); } - ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; + if(vap->va_fsid == um->um_upperdev) + vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; if ((vap != ap->a_vap) && (vap->va_type == VDIR)) ap->a_vap->va_nlink += vap->va_nlink; From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 12:40:51 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AE5316A4CE; Mon, 4 Oct 2004 12:40:51 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6F4443D1F; Mon, 4 Oct 2004 12:40:50 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1CES9Y-0005gw-JA; Mon, 04 Oct 2004 19:41:20 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i94CeXZN023936; Mon, 4 Oct 2004 19:40:33 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i94CeWpk023849; Mon, 4 Oct 2004 19:40:32 +0700 (NOVST) (envelope-from danfe) Date: Mon, 4 Oct 2004 19:40:32 +0700 From: Alexey Dokuchaev To: Uwe Doering Message-ID: <20041004124032.GA22153@regency.nsu.ru> References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU> <41605620.90407@geminix.org> <20041003200803.GA8668@VARK.MIT.EDU> <416069E2.6030403@geminix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416069E2.6030403@geminix.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-fs@freebsd.org cc: bp@freebsd.org cc: David Schultz cc: Takanori Watanabe cc: freebsd-current@freebsd.org Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 12:40:51 -0000 On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: > > As to your concern, in CURRENT this might be fixed already. There, the > unionfs vnode doesn't have an object attached. Instead, calls to > VOP_GETVOBJECT() get forwarded to the underlying file, so the same > object gets referred as for direct modifications of that file. That > should rule out any coherency problems, IMHO. > > Unfortunately, AFAIK, this fix has never been MFC'ed to 4-STABLE. The > respective CVS commits are union_subr.c (rev. 1.51) and union_vnops.c > (rev. 1.82). Any chances they will get merged before 4.11-RELEASE? ./danfe From owner-freebsd-fs@FreeBSD.ORG Mon Oct 4 12:42:54 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5012716A4CE; Mon, 4 Oct 2004 12:42:54 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2F243D41; Mon, 4 Oct 2004 12:42:53 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1CESBZ-0005nd-FI; Mon, 04 Oct 2004 19:43:25 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i94CgcZN025151; Mon, 4 Oct 2004 19:42:38 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i94Cgcn6025112; Mon, 4 Oct 2004 19:42:38 +0700 (NOVST) (envelope-from danfe) Date: Mon, 4 Oct 2004 19:42:38 +0700 From: Alexey Dokuchaev To: Takanori Watanabe Message-ID: <20041004124238.GB22153@regency.nsu.ru> References: <4160FBD9.10603@geminix.org> <200410040912.i949CEjk012965@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410040912.i949CEjk012965@sana.init-main.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-fs@freebsd.org cc: Boris Popov cc: das@freebsd.org cc: freebsd-current@freebsd.org cc: Uwe Doering Subject: Re: Your CVS fix 1.109 to union_vnops.c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 12:42:54 -0000 Hmm. Looks like there's style(9) typo here: > + if(error) ^^ missing space > + goto bad; > + um->um_upperdev = va.va_fsid; And here: > + if(vap->va_fsid == um->um_upperdev) ^^ missing space > + vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; ./danfe