Date: Sun, 03 Oct 2004 21:42:24 +0200 From: Uwe Doering <gemini@geminix.org> To: David Schultz <das@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Your CVS fix 1.109 to union_vnops.c Message-ID: <41605620.90407@geminix.org> In-Reply-To: <20041003183237.GA8100@VARK.MIT.EDU> References: <41601BE0.4050401@geminix.org> <200410031805.i93I5JNZ009076@sana.init-main.com> <20041003183237.GA8100@VARK.MIT.EDU>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
00<cT W[F^ 0
*H
01 0 UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 U TC TrustCenter Class 1 CA1)0' *H
certificate@trustcenter.de0
040428121839Z
050428121839Z0F1 0 UDE10U Uwe Doering1!0 *H
gemini@geminix.org0"0
*H
0
h0:JÔmxǵ 5)rH >A'6fXbosL` YBŮ:,
_NၶT v׀lۙYݥoV6X|^Sx #N>|` I<"#Օ1 x;lb4iv:x8|Zp.H"\Q->fȎS6rֽMU 00 U 0 0U 03 `HB&$http://www.trustcenter.de/guidelines0 `HB0] `HBPNhttps://www.trustcenter.de/cgi-bin/check-rev.cgi/63540000000282575B469B1B5E20?0
*H
Cj]ndd(-_t@r3ZPb: pBRX@a8[( ^F]4 f2( ah2Ν[X1iqGX! fQiuC00<cT W[F^ 0
*H
01 0 UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 U TC TrustCenter Class 1 CA1)0' *H
certificate@trustcenter.de0
040428121839Z
050428121839Z0F1 0 UDE10U Uwe Doering1!0 *H
gemini@geminix.org0"0
*H
0
h0:JÔmxǵ 5)rH >A'6fXbosL` YBŮ:,
_NၶT v׀lۙYݥoV6X|^Sx #N>|` I<"#Օ1 x;lb4iv:x8|Zp.H"\Q->fȎS6rֽMU 00 U 0 0U 03 `HB&$http://www.trustcenter.de/guidelines0 `HB0] `HBPNhttps://www.trustcenter.de/cgi-bin/check-rev.cgi/63540000000282575B469B1B5E20?0
*H
Cj]ndd(-_t@r3ZPb: pBRX@a8[( ^F]4 f2( ah2Ν[X1iqGX! fQiuC1t0p001 0 UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 U TC TrustCenter Class 1 CA1)0' *H
certificate@trustcenter.decT W[F^ 0 + y0 *H
1 *H
0 *H
1
041003194224Z0# *H
1/4s͗H̘
~bQj 0R *H
1E0C0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 U TC TrustCenter Class 1 CA1)0' *H
certificate@trustcenter.decT W[F^ 0 *H
1Ҡ01 0 UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 U TC TrustCenter Class 1 CA1)0' *H
certificate@trustcenter.decT W[F^ 0
*H
%f+BU!բy>P֭b<tJVO>}هZ,5KN Q2=wE@6qwl&E鑝4Kcѯ
>Z38y6m R[UA2 PlLZ53O ANDEZ !˞!=jf%(} @a)X*4=zFǮYw ȔzU$Էٵf\ ,Řoe)s뉠d[7<
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41605620.90407>