Re: Your CVS fix 1.109 to union_vnops.c

From: Takanori Watanabe (takawata_at_init-main.com)
Date: 10/03/04

  • Next message: Uwe Doering: "Re: Your CVS fix 1.109 to union_vnops.c" 
    To: Uwe Doering <gemini@geminix.org>
Date: Mon, 04 Oct 2004 03:05:19 +0900

    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
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Uwe Doering: "Re: Your CVS fix 1.109 to union_vnops.c"

    Relevant Pages