From owner-freebsd-questions@FreeBSD.ORG Thu Jul 1 21:50:28 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A0916A4CE for ; Thu, 1 Jul 2004 21:50:28 +0000 (GMT) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A9DD43D31 for ; Thu, 1 Jul 2004 21:50:27 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1])i61Lmxmg075060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jul 2004 22:48:59 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)id i61LmxUn075059; Thu, 1 Jul 2004 22:48:59 +0100 (BST) (envelope-from matthew) Date: Thu, 1 Jul 2004 22:48:59 +0100 From: Matthew Seaman To: Alex K Message-ID: <20040701214859.GA74742@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: Matthew Seaman , Alex K , freebsd-questions@freebsd.org References: <200407020104.32927.lesha@intercaf.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <200407020104.32927.lesha@intercaf.ru> User-Agent: Mutt/1.5.6i X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.5.3 (smtp.infracaninophile.co.uk [0.0.0.0]); Thu, 01 Jul 2004 22:48:59 +0100 (BST) X-Virus-Scanned: clamd / ClamAV version devel-20040612, clamav-milter version 0.72a on smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on happy-idiot-talk.infracaninophile.co.uk cc: freebsd-questions@freebsd.org Subject: Re: du -k VS ls -l (what I'm missing?) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2004 21:50:28 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 02, 2004 at 01:04:32AM +0400, Alex K wrote: > what do I miss here? > sum of individual file sizes is much more than "total" in ls and more tha= n du -k reports >=20 > bash-2.05b$ ls -l > total 354112 > -rw-r--r-- 1 lesha wheel 98490960 1 ??? 12:29 88479E51B1D77190A2A8C8= 82 > -rw-r--r-- 1 lesha wheel 299376716 25 ??? 15:20 F445555AA5CA2D90F33EE0= F1 > -rw-r--r-- 1 lesha wheel 540729348 1 ??? 19:01 0C859D601337F1D26D68BA= 90 > -rw-r--r-- 1 lesha wheel 125204414 30 ??? 18:12 50922168AB8D4CB73FA390= 63 > -rw-r--r-- 1 lesha wheel 365164364 1 ??? 12:06 CBB789334BF480B9ED153E= A8 > -rw-r--r-- 1 lesha wheel 209031053 30 ??? 19:05 B2AFAA6C8C68575BA97476= F4 > -rw-r--r-- 1 lesha wheel 336457988 29 ??? 17:43 200DCA96AFFAF2FB08E3E2= 79 > -rw-r--r-- 1 lesha wheel 40714776 1 ??? 18:16 6E30F671D9F305458A0936= 17 > -rw-r--r-- 1 lesha wheel 209945132 25 ??? 15:29 A515D96BFAD85C294D4A9B= B7 > -rw-r--r-- 1 lesha wheel 114632620 1 ??? 18:25 7868FE483F37D653109E67= B3 > -rw-r--r-- 1 lesha wheel 242241614 1 ??? 19:02 75B7DC03642E00CE564C1F= F6 > -rw-r--r-- 1 lesha wheel 42681134 25 ??? 15:29 F9C3246915327E44B9B0FD= 2C > -rw-r--r-- 1 lesha wheel 165569384 30 ??? 18:54 4FCA6EC8E3AB33B33E3E50= 11 > bash-2.05b$ du -k > 354114 . > bash-2.05b$ The 'total' figure from ls(1) and the number shown by du(1) is the total disk usage in blocks of 1024 bytes (if BLOCKSIZE=3Dk is set in your environment, which is the default) -- in this case, about a factor of 7 smaller than the total of the file sizes. Files can have 'holes' -- parts of the file that have never been written to, although later parts of the file have. Disk blocks are not allocated for those unwritten areas. If you use hexdump(1) on the file, the holes will show up as a sequence of null bytes. The way to tell if a file is holey is to compare the size of the file against the number of blocks allocated for it using: % stat -f "%10z %6b %N" * [ or % ls -ls * where the 1st column is the number of blocks, the 6th is the filesize in bytes] If the filesize is significantly greater than the number of blocks multiplied by the block size (stat(1) shows 512 byte blocks, ls(1) shows 1024 byte blocks) then those files have holes in them. It's quite common to see this, for example, in files that are the backing stores for databases. Having holey files is not a problem, although some broken backup software will tend to fill in all of the gaps with zeros, meaning that occasionally you can't restore a file back onto the same partition it was backed up from. You can quite easily have a file whose apparent size is larger than the partition holding it. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA5IbLiD657aJF7eIRAmgnAKCWfCalUrdueaQ1F3+RqNTYOw/OTACfbu4p qmdioOjMSsW+j9voteGGbmk= =3kGP -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--