From owner-freebsd-fs@FreeBSD.ORG Sun Apr 21 06:34:36 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C0C5DA2; Sun, 21 Apr 2013 06:34:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id BD7C584A; Sun, 21 Apr 2013 06:34:35 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3L6YRNp021705; Sun, 21 Apr 2013 16:34:27 +1000 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3L6YEWm019132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 16:34:16 +1000 Date: Sun, 21 Apr 2013 16:34:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon Subject: Re: kern/177985: [zfs] disk usage problem when copying from one zfs dataset to another on the same pool using mv command In-Reply-To: <201304202030.r3KKU1uu001300@freefall.freebsd.org> Message-ID: <20130421154040.A888@besplex.bde.org> References: <201304202030.r3KKU1uu001300@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=S7iBW/QP c=1 sm=1 a=L-je8UQNzmIA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=FVYdBsR1Ul8A:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=vpiTI7J_NP48tiGzyMIA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=MSl-tDqOz04A:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 06:34:36 -0000 On Sat, 20 Apr 2013, Andriy Gapon wrote: > The following reply was made to PR kern/177985; it has been noted by GNATS. > > From: Andriy Gapon > To: Jon > Cc: "bug-followup@FreeBSD.org" > Subject: Re: kern/177985: [zfs] disk usage problem when copying from one zfs > dataset to another on the same pool using mv command > Date: Sat, 20 Apr 2013 23:25:40 +0300 > > on 20/04/2013 22:49 Jon said the following: > ... > > This all can be > > accomplished by deleting copied files more often than it currently does or at > > least adding a flag to turn on synchronized deletes. > > No, it can not be accomplished that way, because it would violate how mv(1) > across filesystems works. Perhaps it's indeed the time to read the man page? The behaviour of not removing the source tree until after successful copying of the whole tree is also specified by POSIX, although a little unclearly. I thought that POSIX specified the FreeBSD behaviour (of using cp -pRP to move across file systems, and then rm -rf of the source path only if the cp succeeded). But it seems to have a subtle different that makes FreeBSD's implementation invalid (apart from the bugs in cp -pRP): - for cp -R, it is optional whether cp continues with remaining files (in the hierarchy under the current "source file" after a write error. FreeBSD's copy does continue. - for cp -R, the continuing after most other errors (e.g., for open()) is not permitted, but FreeBSD's cp continues. - for mv across file systems, not continuing after write errors seems to be required, although a little unclearly. From POSIX.1-2001-draft7: @ 25182 If the duplication of the file hierarchy fails for any reason, mv shall write a diagnostic @ 25183 message to standard error, do nothing more with the current source_file, and go on to any @ 25184 remaining source_files. This is fuzzy about when the error for duplication of the file hierarchy must be detected and acted on, but any reasonable implementation will detect errors for individual files as they are copied (modulo not detecting async write errors until much later if at all), and then it takes a weaselish reading of the above to allow the FreeBSD behaviour of not quitting as soon as the error is detected, but instead buffering this error and only reporting it after trying to copy all the other files. Quitting here is the only way for avoiding falling through to clause 6 which specifies removing the source hierarchy. @ 25185 If the duplication of the file characteristics fails for any reason, mv shall write a diagnostic @ 25186 message to standard error, but this failure shall not cause mv to modify its exit status. Continuing in this case is correct. Not modifying the exit status in this case is a bug in the spec IMO. However, FreeBSD's implementation doesn't have this bug. For cp -p, the error handling for failing to copy attributes is underspecified in POSIX (some cases are specified to write a diagnostic on error, but no cases that I could find are specified to set the exit status for such errors). FreeBSD's cp -p sets the exit status for all failures to copy attributes. FreeBSD's mv across file system inherits this behaviour. Thus failure to duplicate a single attribute in a large hierarchy causes the whole cp to report falure to mv, and mv then consequently modifies its exit status and refuses to remove the source hierarchy, so it doesn't have this bug. In some cases, the attributes might be important and their might be billions of failures to duplicate them. Then you don't want the only copy of them in the source hierarchy being removed. @ 25187 6. The file hierarchy rooted in source_file shall be removed. If this fails for any reason, mv shall @ 25188 write a diagnostic message to the standard error, do nothing more with the current @ 25189 source_file, and go on to any remaining source_files. We get here for no error in the cp for FreeBSD, or for no error except for duplicating attributes in POSIX. Again the spec is fuzzy about when "fails for any reason" is. Now it seems best to continue after errors in intermediate steps, and that is what FreeBSD's rm -rf does. (We know that this rm -rf is safer than most, since we have just made a copy successfully.) POSIX rm -r seems to require continuing after most errors. Bruce