From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 20:18:08 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 353D216A4DD for ; Tue, 1 Aug 2006 20:18:08 +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 7757743D5C for ; Tue, 1 Aug 2006 20:18:07 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 5386 invoked by uid 2001); 1 Aug 2006 20:18:06 -0000 Date: Tue, 1 Aug 2006 15:18:06 -0500 From: "Rick C. Petty" To: Peter Jeremy Message-ID: <20060801201806.GC4272@megan.kiwi-computer.com> References: <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> <20060801190453.GD717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801190453.GD717@turion.vk2pj.dyndns.org> 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 20:18:08 -0000 On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote: > >string of zeros larger than the block size, or it needs to 'do the right > >thing' and determine if it's sparse or not. > > You can do this by comparing stat.st_size with stat.st_blocks - a > sparse file will have fewer blocks than its size requires. What you > can't do is accurately determine where the holes are. > > Note that st_blksize is not nessarily the allocation blocksize and > therefore is unrelated to the size of holes in the filesystem. Also, > on FreeBSD, the designation of "optimal" is a misnomer and I/O > operations should be much larger than this for optimal efficiency. True, but I've not seen the case where the following is not true: The filesystem's block size (i.e. 8x fragment size) in UFS an integer multiple of st_blksize. My previously-posted example would work just fine. I guess a better solution would be to check every 512-byte chunk and seek if zero. It's up to the underlying filesystem to implement this as a sparse file, if that filesystem supports such a thing. -- Rick C. Petty