From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:20:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B767416A50A for ; Tue, 1 Aug 2006 18:20:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 24F3F43D5A for ; Tue, 1 Aug 2006 18:20:40 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 4341 invoked by uid 2001); 1 Aug 2006 18:00:40 -0000 Date: Tue, 1 Aug 2006 13:00:40 -0500 From: "Rick C. Petty" To: Eric Anderson Message-ID: <20060801180040.GA4272@megan.kiwi-computer.com> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CF94A4.3000306@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:20:46 -0000 On Tue, Aug 01, 2006 at 12:51:32PM -0500, Eric Anderson wrote: > On 08/01/06 12:40, Rick C. Petty wrote: > > It could possibly be bad if you have a real file (say a 10GB file, > partially filled with zeros - a disk image created with dd for > instance), and you use cp with something like -spR to recursively copy > all files. Your destination disk image would then be a sparse file, so > additional changes and modifications to the file (block allocations) > would fragment the image and make it slower. That would be unexpected > and probably go unnoticed for some time. I do see the usefulness in > this, but I think one needs to be careful to either clearly note in the > man page that it will make sparse files from *any* file containing a > string of zeros larger than the block size, I completely agree. This is why it would not be the default behavior. Also, gnutar provides this option and it just describes it as "handle sparse files efficiently"-- so a rewording of that to say that by "efficient" we mean that the program will allocate as few blocks as possible in the underlying filesystem. I think a clear description in the man page would suffice. > or it needs to 'do the right > thing' and determine if it's sparse or not. Unfortunately that would require knowledge which the POSIX calls have no knowledge of. I don't believe we should roll filesystem-specific knowledge into cp. However, there is utility in performing a "space-saving" copy, just as a hardlink is quite space-saving. =) "-s" or "-S" could refer to sparse, space, squeeze, shrink, or whatever. -- Rick C. Petty