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 >> _at__at_ -951,6 +951,8 _at__at_ >> 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); >> } >> _at__at_ -972,7 +974,6 _at__at_ >> 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.netReceived on Mon Oct 04 2004 - 05:50:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC