Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!gnu From: gnu@sun.uucp (John Gilmore) Newsgroups: net.unix,net.unix-wizards Subject: Re: Tar Padding Nulls Advice Message-ID: <2425@sun.uucp> Date: Tue, 16-Jul-85 05:40:32 EDT Article-I.D.: sun.2425 Posted: Tue Jul 16 05:40:32 1985 Date-Received: Thu, 18-Jul-85 06:01:17 EDT References: <691@rlgvax.UUCP> Organization: Sun Microsystems, Inc. Lines: 18 Xref: watmath net.unix:5051 net.unix-wizards:13867 > We have a data base program that allocates nulls in the middle of > the file to use for data expansion. This may be created as a > 1MB file, but only be a 1KB file of data. UNIX only really allocates 1 block > for this file. If we tar, cpio, or cp this file, the file becomes > fully allocated as the nulls are fully padded. This is a problem > since a backup may no longer fit on the same file system. Any > suggestions as to ways around this other than hacking tar, cpio, and cp? I think the preferred way of handling this is for the kernel file system to check when you write, to see if you wrote all zeros. The circumstances of the test can be suitably restricted to avoid overhead, e.g. only do the check if the block being written to is currently a hole and the first 4 bytes of the write are zero (compare the first long to 0). This fixes the tar/dump/cp/cpio problem. It would be slightly more intuitive if the file system never stored a block of all zeros on disk (and this could be depended on by users) but the compromise above fixes most of the things that bite people today.