From owner-cvs-all Tue Oct 2 10:34: 6 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B220F37B408; Tue, 2 Oct 2001 10:34:01 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f92HXwI58562; Tue, 2 Oct 2001 10:33:58 -0700 (PDT) (envelope-from dillon) Date: Tue, 2 Oct 2001 10:33:58 -0700 (PDT) From: Matt Dillon Message-Id: <200110021733.f92HXwI58562@earth.backplane.com> To: Poul-Henning Kamp Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c References: <18752.1002008770@critter.freebsd.dk> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :In message <200110020426.f924Qw605686@freefall.freebsd.org>, Matt Dillon writes :: :>dillon 2001/10/01 21:26:58 PDT :> :> Modified files: :> sys/ufs/ufs ufs_vnops.c :> Log: :> Backout the last commit. The problem is actually much worse then I :> first thought and may require serious work to the VOP_RENAME() api itself. :> Basically, by the time the VOP_RENAME() function is called, it's already :> too late. : :I chatted with Rob Pike about rename, in particular in the context of :remote filesystems and plan9. : :To avoid the nightmare of our VOP_RENAME, in plan9 you can only rename :inside one directory. : :While not an option for us, I can certainly see why they did that... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 'nightmare' is exactly the right word. There is no simple fix to this... by the time VOP_RENAME is called, it's already too late. Even flagging the vnode representing the source in the namei() call itself, prior to unlocking it, is not sufficient because the relookup() inside VOP_RENAME will still fail if someone renames one of the parent directories in the source path. We can't lock the source dir/vnode AND the destination dir/vnode because of the potential to deadlock with other processes. We can't switch around which one the syscall locks (lock the source instead of the destination) without changing the VOP_RENAME api. We can't undo the UFS code - it does (and must do) the relookup after linking the destination. In short, we're screwed. I am going to attempt to do a workaround that checks the link count in the inode to determine if the rename() can proceed after the relookup() call fails. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message