Your CVS fix 1.109 to union_vnops.c
Uwe Doering
gemini at geminix.org
Mon Oct 4 00:50:57 PDT 2004
Uwe Doering wrote:
> takawata at 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 at geminix.org | http://www.escapebox.net
More information about the freebsd-current
mailing list