Any help appreciated.

Edward.

------_=_NextPart_001_01C5E6B4.EEBE73D1-- ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: Rename window Date: Fri, 11 Nov 2005 08:30:36 -0500 Message-ID: <20051111133036.GA3847@hmsendeavour.rdu.redhat.com> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaYzW-00034P-AH for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:30:54 -0800 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1EaYzU-0001nl-SU for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:30:54 -0800 To: Edward Hibbert In-Reply-To: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, Nov 11, 2005 at 11:42:01AM -0000, Edward Hibbert wrote: > I have noticed a atomicity problem with the handling of rename by the > Linux NFS client, and just wanted to check if this is something that we > just have to work-around, or is there some other solution. > > The problem arises when two different machines issue a file rename which > is identical. > > E.g. rename oldname newname > > You would expect that one machine would be successful, and the other > would fail. However, the NFS client seems to be issuing 3 NFS > operations to perform the rename > > * LOOKUP oldname > * LOOKUP newname > * RENAME oldname newname > > There is a timing window where both LOOKUPs can succeed (if the other > machine does the rename at the right time). In this case, the Linux > NFS client does not issue the final NFS RENAME operation - BUT still > returns success to the caller. > > Thus both machines have succeeded in renaming the file. > > You might argue that since they are performing the same operation that > it is OK for both to succeed, but I have an application that depends on > the atomicity of the operation, as it uses the filename to hold a > counter, and rename to assign a unique counter to a process. > > Any help appreciated. > I don't believe rename ever guaranteed atomicity of its operation. If you want to guarantee atomicity I expect you will want to implement a locking strategy around the directories/files you are modifying in the rename operation using fcntl locking. Regards Neil > Edward. > > -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Rename window Date: Fri, 11 Nov 2005 08:38:36 -0500 Message-ID: <1131716316.8805.16.camel@lade.trondhjem.org> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain Cc: nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaZ7H-0003Nk-7l for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:38:55 -0800 Received: from pat.uio.no ([129.240.130.16] ident=7411) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1EaZ7F-0003Ts-U7 for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:38:55 -0800 To: Edward Hibbert In-Reply-To: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote: > I have noticed a atomicity problem with the handling of rename by the > Linux NFS client, and just wanted to check if this is something that > we just have to work-around, or is there some other solution. > > The problem arises when two different machines issue a file rename > which is identical. > > E.g. rename oldname newname > > You would expect that one machine would be successful, and the other > would fail. However, the NFS client seems to be issuing 3 NFS > operations to perform the rename > * LOOKUP oldname > * LOOKUP newname > * RENAME oldname newname > There is a timing window where both LOOKUPs can succeed (if the other > machine does the rename at the right time). In this case, the Linux > NFS client does not issue the final NFS RENAME operation - BUT still > returns success to the caller. > > Thus both machines have succeeded in renaming the file. > > You might argue that since they are performing the same operation that > it is OK for both to succeed, but I have an application that depends > on the atomicity of the operation, as it uses the filename to hold a > counter, and rename to assign a unique counter to a process. This is another of those cases where the VFS has optimised for local filesystem behaviour, and where fixing this problem would require significant VFS changes. You'd basically have to add a new lookup intent for the RENAME function in order to tell the NFS layer that it can ignore the lookup requests. We probably will get round to doing that sometime, but it is not one of the most pressing bugs on my list. In the meantime, I'd suggest just not relying on this level of atomicity (there are in any case situations where this is always impossible - for instance in sillyrename() situations). Cheers, Trond ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Rename window Date: Fri, 11 Nov 2005 08:41:12 -0500 Message-ID: <1131716472.8805.19.camel@lade.trondhjem.org> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> <20051111133036.GA3847@hmsendeavour.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Edward Hibbert , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaZ9w-0003Xm-LT for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:41:40 -0800 Received: from pat.uio.no ([129.240.130.16] ident=7411) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1EaZ9w-0004B8-7b for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 05:41:40 -0800 To: Neil Horman In-Reply-To: <20051111133036.GA3847@hmsendeavour.rdu.redhat.com> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 2005-11-11 at 08:30 -0500, Neil Horman wrote: > I don't believe rename ever guaranteed atomicity of its operation. If you want > to guarantee atomicity I expect you will want to implement a locking strategy > around the directories/files you are modifying in the rename operation using fcntl > locking. No. Edward is correct in that a POSIX filesystem is supposed to guarantee atomicity (this is one reason why we have a dedicated rename() instead of playing games like link(a,b); unlink(b);). Unfortunately, as I said, there are issues in the VFS... Cheers, Trond ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: Rename window Date: Fri, 11 Nov 2005 09:58:02 -0500 Message-ID: <4374B17A.7030806@redhat.com> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> <1131716316.8805.16.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Edward Hibbert , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaaM8-0006ke-ER for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 06:58:20 -0800 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1EaaM7-0003DP-A8 for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 06:58:20 -0800 To: Trond Myklebust In-Reply-To: <1131716316.8805.16.camel@lade.trondhjem.org> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Trond Myklebust wrote: >On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote: > > >>I have noticed a atomicity problem with the handling of rename by the >>Linux NFS client, and just wanted to check if this is something that >>we just have to work-around, or is there some other solution. >> >>The problem arises when two different machines issue a file rename >>which is identical. >> >>E.g. rename oldname newname >> >>You would expect that one machine would be successful, and the other >>would fail. However, the NFS client seems to be issuing 3 NFS >>operations to perform the rename >> * LOOKUP oldname >> * LOOKUP newname >> * RENAME oldname newname >>There is a timing window where both LOOKUPs can succeed (if the other >>machine does the rename at the right time). In this case, the Linux >>NFS client does not issue the final NFS RENAME operation - BUT still >>returns success to the caller. >> >>Thus both machines have succeeded in renaming the file. >> >>You might argue that since they are performing the same operation that >>it is OK for both to succeed, but I have an application that depends >>on the atomicity of the operation, as it uses the filename to hold a >>counter, and rename to assign a unique counter to a process. >> >> > >This is another of those cases where the VFS has optimised for local >filesystem behaviour, and where fixing this problem would require >significant VFS changes. >You'd basically have to add a new lookup intent for the RENAME function >in order to tell the NFS layer that it can ignore the lookup requests. >We probably will get round to doing that sometime, but it is not one of >the most pressing bugs on my list. > >In the meantime, I'd suggest just not relying on this level of atomicity >(there are in any case situations where this is always impossible - for >instance in sillyrename() situations). > It is true that rename(2) is supposed to be atomic. It is also true that this is a problem in an optimization in the file system independent layer in the current Linux. There is a check which compares the "from" inode and the "to" inode and, if they are the same, just returns no error, ie. success. NFS does need at least the lookup on the "to" name so that it can handle the rename to an open file case. Couldn't this be (fairly) easily handled by making the short circuit check in vfs_rename() conditional and not use it for NFS mounted file systems and perhaps others? Thanx... ps ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Rename window Date: Fri, 11 Nov 2005 10:13:03 -0500 Message-ID: <1131721983.8805.48.camel@lade.trondhjem.org> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> <1131716316.8805.16.camel@lade.trondhjem.org> <4374B17A.7030806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Edward Hibbert , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Eaaax-0007Vn-7h for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:13:39 -0800 Received: from pat.uio.no ([129.240.130.16] ident=7411) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Eaaar-0000m5-LP for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:13:36 -0800 To: Peter Staubach In-Reply-To: <4374B17A.7030806@redhat.com> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 2005-11-11 at 09:58 -0500, Peter Staubach wrote: > Trond Myklebust wrote: > > >On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote: > > > > > >>I have noticed a atomicity problem with the handling of rename by the > >>Linux NFS client, and just wanted to check if this is something that > >>we just have to work-around, or is there some other solution. > >> > >>The problem arises when two different machines issue a file rename > >>which is identical. > >> > >>E.g. rename oldname newname > >> > >>You would expect that one machine would be successful, and the other > >>would fail. However, the NFS client seems to be issuing 3 NFS > >>operations to perform the rename > >> * LOOKUP oldname > >> * LOOKUP newname > >> * RENAME oldname newname > >>There is a timing window where both LOOKUPs can succeed (if the other > >>machine does the rename at the right time). In this case, the Linux > >>NFS client does not issue the final NFS RENAME operation - BUT still > >>returns success to the caller. > >> > >>Thus both machines have succeeded in renaming the file. > >> > >>You might argue that since they are performing the same operation that > >>it is OK for both to succeed, but I have an application that depends > >>on the atomicity of the operation, as it uses the filename to hold a > >>counter, and rename to assign a unique counter to a process. > >> > >> > > > >This is another of those cases where the VFS has optimised for local > >filesystem behaviour, and where fixing this problem would require > >significant VFS changes. > >You'd basically have to add a new lookup intent for the RENAME function > >in order to tell the NFS layer that it can ignore the lookup requests. > >We probably will get round to doing that sometime, but it is not one of > >the most pressing bugs on my list. > > > >In the meantime, I'd suggest just not relying on this level of atomicity > >(there are in any case situations where this is always impossible - for > >instance in sillyrename() situations). > > > > It is true that rename(2) is supposed to be atomic. > > It is also true that this is a problem in an optimization in the file system > independent layer in the current Linux. There is a check which compares the > "from" inode and the "to" inode and, if they are the same, just returns no > error, ie. success. NFS does need at least the lookup on the "to" name so > that it can handle the rename to an open file case. > > Couldn't this be (fairly) easily handled by making the short circuit check > in vfs_rename() conditional and not use it for NFS mounted file systems > and perhaps others? That causes weird behaviour to pop up in other places. One classic is the rename of an open file onto a hard link of itself, where unless someone (either NFS or the VFS) tests those inodes for equality, NFS will end up sillyrenaming the hard link, then renaming the open file in complete violation of POSIX. Cheers, Trond ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: Rename window Date: Fri, 11 Nov 2005 10:25:02 -0500 Message-ID: <4374B7CE.6030508@redhat.com> References: <9E621559095AA746B22B21CD4FAF99A557356D@EDINMAIL1.ad.datcon.co.uk> <1131716316.8805.16.camel@lade.trondhjem.org> <4374B17A.7030806@redhat.com> <1131721983.8805.48.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Edward Hibbert , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaamA-00089I-KE for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:25:14 -0800 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1EaamA-0000Yy-7A for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:25:14 -0800 To: Trond Myklebust In-Reply-To: <1131721983.8805.48.camel@lade.trondhjem.org> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Trond Myklebust wrote: >On Fri, 2005-11-11 at 09:58 -0500, Peter Staubach wrote: > > >>Trond Myklebust wrote: >> >> >> >>>On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote: >>> >>> >>> >>> >>>>I have noticed a atomicity problem with the handling of rename by the >>>>Linux NFS client, and just wanted to check if this is something that >>>>we just have to work-around, or is there some other solution. >>>> >>>>The problem arises when two different machines issue a file rename >>>>which is identical. >>>> >>>>E.g. rename oldname newname >>>> >>>>You would expect that one machine would be successful, and the other >>>>would fail. However, the NFS client seems to be issuing 3 NFS >>>>operations to perform the rename >>>> * LOOKUP oldname >>>> * LOOKUP newname >>>> * RENAME oldname newname >>>>There is a timing window where both LOOKUPs can succeed (if the other >>>>machine does the rename at the right time). In this case, the Linux >>>>NFS client does not issue the final NFS RENAME operation - BUT still >>>>returns success to the caller. >>>> >>>>Thus both machines have succeeded in renaming the file. >>>> >>>>You might argue that since they are performing the same operation that >>>>it is OK for both to succeed, but I have an application that depends >>>>on the atomicity of the operation, as it uses the filename to hold a >>>>counter, and rename to assign a unique counter to a process. >>>> >>>> >>>> >>>> >>>This is another of those cases where the VFS has optimised for local >>>filesystem behaviour, and where fixing this problem would require >>>significant VFS changes. >>>You'd basically have to add a new lookup intent for the RENAME function >>>in order to tell the NFS layer that it can ignore the lookup requests. >>>We probably will get round to doing that sometime, but it is not one of >>>the most pressing bugs on my list. >>> >>>In the meantime, I'd suggest just not relying on this level of atomicity >>>(there are in any case situations where this is always impossible - for >>>instance in sillyrename() situations). >>> >>> >>> >>It is true that rename(2) is supposed to be atomic. >> >>It is also true that this is a problem in an optimization in the file system >>independent layer in the current Linux. There is a check which compares the >>"from" inode and the "to" inode and, if they are the same, just returns no >>error, ie. success. NFS does need at least the lookup on the "to" name so >>that it can handle the rename to an open file case. >> >>Couldn't this be (fairly) easily handled by making the short circuit check >>in vfs_rename() conditional and not use it for NFS mounted file systems >>and perhaps others? >> >> > >That causes weird behaviour to pop up in other places. One classic is >the rename of an open file onto a hard link of itself, where unless >someone (either NFS or the VFS) tests those inodes for equality, NFS >will end up sillyrenaming the hard link, then renaming the open file in >complete violation of POSIX. > I suppose that a check could be added for the hard link count, but yuck, that is a nasty situation. Oh well, good point... ps ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Edward Hibbert" Subject: RE: Rename window Date: Fri, 11 Nov 2005 15:28:04 -0000 Message-ID: <9E621559095AA746B22B21CD4FAF99A55735BC@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Eaap8-0008HM-GF for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:28:18 -0800 Received: from smtp2.dataconnection.com ([192.91.191.8]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1Eaap8-0006dV-15 for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:28:18 -0800 To: "Peter Staubach" , "Trond Myklebust" Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Thanks for your replies. We're getting round this by ensuring that we don't rename to the same name - we can put something machine-specific in the destination filename fairly easily. However I should probably have said that our test app suggests this doesn't occur with Solaris NFS clients, which might influence people's opinion on whether it should be fixed. Regards, Edward. -----Original Message----- From: Peter Staubach [mailto:staubach@redhat.com]=20 Sent: 11 November 2005 15:25 To: Trond Myklebust Cc: Edward Hibbert; nfs@lists.sourceforge.net Subject: Re: [NFS] Rename window Trond Myklebust wrote: >On Fri, 2005-11-11 at 09:58 -0500, Peter Staubach wrote: > =20 > >>Trond Myklebust wrote: >> >> =20 >> >>>On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote: >>>=20 >>> >>> =20 >>> >>>>I have noticed a atomicity problem with the handling of rename by=20 >>>>the Linux NFS client, and just wanted to check if this is something=20 >>>>that we just have to work-around, or is there some other solution. >>>> >>>>The problem arises when two different machines issue a file rename=20 >>>>which is identical. >>>> >>>>E.g. rename oldname newname >>>> >>>>You would expect that one machine would be successful, and the other >>>>would fail. However, the NFS client seems to be issuing 3 NFS >>>>operations to perform the rename >>>> * LOOKUP oldname=20 >>>> * LOOKUP newname=20 >>>> * RENAME oldname newname >>>>There is a timing window where both LOOKUPs can succeed (if the other >>>>machine does the rename at the right time). In this case, the Linux >>>>NFS client does not issue the final NFS RENAME operation - BUT still >>>>returns success to the caller. >>>> >>>>Thus both machines have succeeded in renaming the file. >>>> >>>>You might argue that since they are performing the same operation=20 >>>>that it is OK for both to succeed, but I have an application that=20 >>>>depends on the atomicity of the operation, as it uses the filename=20 >>>>to hold a counter, and rename to assign a unique counter to a process. >>>> =20 >>>> >>>> =20 >>>> >>>This is another of those cases where the VFS has optimised for local=20 >>>filesystem behaviour, and where fixing this problem would require=20 >>>significant VFS changes. >>>You'd basically have to add a new lookup intent for the RENAME=20 >>>function in order to tell the NFS layer that it can ignore the lookup requests. >>>We probably will get round to doing that sometime, but it is not one=20 >>>of the most pressing bugs on my list. >>> >>>In the meantime, I'd suggest just not relying on this level of=20 >>>atomicity (there are in any case situations where this is always=20 >>>impossible - for instance in sillyrename() situations). >>> >>> =20 >>> >>It is true that rename(2) is supposed to be atomic. >> >>It is also true that this is a problem in an optimization in the file=20 >>system independent layer in the current Linux. There is a check which >>compares the "from" inode and the "to" inode and, if they are the=20 >>same, just returns no error, ie. success. NFS does need at least the=20 >>lookup on the "to" name so that it can handle the rename to an open file case. >> >>Couldn't this be (fairly) easily handled by making the short circuit=20 >>check in vfs_rename() conditional and not use it for NFS mounted file=20 >>systems and perhaps others? >> =20 >> > >That causes weird behaviour to pop up in other places. One classic is=20 >the rename of an open file onto a hard link of itself, where unless=20 >someone (either NFS or the VFS) tests those inodes for equality, NFS=20 >will end up sillyrenaming the hard link, then renaming the open file in >complete violation of POSIX. > I suppose that a check could be added for the hard link count, but yuck, that is a nasty situation. Oh well, good point... ps ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: RE: Rename window Date: Fri, 11 Nov 2005 10:29:19 -0500 Message-ID: <1131722959.8805.53.camel@lade.trondhjem.org> References: <9E621559095AA746B22B21CD4FAF99A55735BC@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain Cc: Peter Staubach , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1EaaqS-0008Ku-Fs for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:29:40 -0800 Received: from pat.uio.no ([129.240.130.16] ident=7411) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1EaaqR-0006ww-Ve for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:29:40 -0800 To: Edward Hibbert In-Reply-To: <9E621559095AA746B22B21CD4FAF99A55735BC@EDINMAIL1.ad.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 2005-11-11 at 15:28 +0000, Edward Hibbert wrote: > However I should probably have said that our test app suggests this > doesn't occur with Solaris NFS clients, which might influence people's > opinion on whether it should be fixed. Not really, no. ;-) Cheers, Trond ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Edward Hibbert" Subject: RE: Rename window Date: Fri, 11 Nov 2005 15:31:42 -0000 Message-ID: <9E621559095AA746B22B21CD4FAF99A55735BF@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Peter Staubach" , Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Eaasa-0008Up-Au for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:31:52 -0800 Received: from smtp2.dataconnection.com ([192.91.191.8]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1EaasZ-0007R8-OX for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:31:52 -0800 To: "Trond Myklebust" Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Hey, who said "it" couldn't refer to "Solaris"? Edward.=20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: 11 November 2005 15:29 To: Edward Hibbert Cc: Peter Staubach; nfs@lists.sourceforge.net Subject: RE: [NFS] Rename window On Fri, 2005-11-11 at 15:28 +0000, Edward Hibbert wrote: > However I should probably have said that our test app suggests this=20 > doesn't occur with Solaris NFS clients, which might influence people's > opinion on whether it should be fixed. Not really, no. ;-) Cheers, Trond ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: Rename window Date: Fri, 11 Nov 2005 10:33:07 -0500 Message-ID: <4374B9B3.6030905@redhat.com> References: <9E621559095AA746B22B21CD4FAF99A55735BC@EDINMAIL1.ad.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: Trond Myklebust , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Eaatx-00006Z-IV for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:33:17 -0800 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1Eaatw-0002UQ-2S for nfs@lists.sourceforge.net; Fri, 11 Nov 2005 07:33:17 -0800 To: Edward Hibbert In-Reply-To: <9E621559095AA746B22B21CD4FAF99A55735BC@EDINMAIL1.ad.datcon.co.uk> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Edward Hibbert wrote: >Thanks for your replies. We're getting round this by ensuring that we >don't rename to the same name - we can put something machine-specific in >the destination filename fairly easily. > >However I should probably have said that our test app suggests this >doesn't occur with Solaris NFS clients, which might influence people's >opinion on whether it should be fixed. > I'd be surprised if this couldn't happen with Solaris clients. They do the same lookups and have many of the same decision making statements. It is implemented differently, completely down in the NFS file system, but it works about the same. ps ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs