Date: Wed, 21 Jul 2004 22:31:05 +0200 From: Daniel Lang <dl@leo.org> To: Brooks Davis <brooks@one-eyed-alien.net>, harti@freebsd.org, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: current@freebsd.org Subject: Re: NEW TAR Message-ID: <20040721203105.GA55687@atrbg11.informatik.tu-muenchen.de> In-Reply-To: <200407211622.i6LGMZrm040478@khavrinen.lcs.mit.edu> <20040721162706.GA12760@Odin.AC.HMC.Edu> References: <Pine.GSO.4.61.0407211440210.28037@mail.ilrt.bris.ac.uk> <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> <200407211622.i6LGMZrm040478@khavrinen.lcs.mit.edu> <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <20040720081051.GB3001@cirb503493.alcatel.com.au> <B82A97D5-DA91-11D8-B0C4-000A95C893E4@lassitu.de> <Pine.GSO.4.61.0407211440210.28037@mail.ilrt.bris.ac.uk> <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> <20040721162706.GA12760@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Brooks Davis wrote on Wed, Jul 21, 2004 at 09:27:06AM -0700: [..] > Since sparse files over commit the disk, they should only be created > deliberatly. Otherwise you can easily get in trouble if you try to use > reserved space later since it won't actually be reserved. Consider the > case of a file system image created with "dd if=/dev/zero ...; newfw > ...". If your archiver decides to be "smart" and restore a copy of that > file sparce and then you use up the availble blocks on your disk you're > going to be in a world of hurt. I wouldn't be suprised it that resulted > in a panic. [Garret writes:] > You've never run out of disk space as a result of a sparse file > becoming non-sparse? That was not my point. I agree, that it should be done deliberately. There should be a non-default command-line switch to enable sparse files or not (as it is common practice now anyway). But if someone chooses to use sparse files upon archive extraction (I believe this is the more important part), it does not matter how the original file layout was in terms of blocks of allocated zeroes and unallocated blocks. To Harti: I admit I don't know for sure, but to my understanding the handling of the sparse file is done in the filesystem layer and not in the application, right? Then all possible performance benefit on reading a sparse file should be gained anyway. Regardless if the application (the archiver) knows about the locations of the gaps or not.... Best regards, Daniel -- IRCnet: Mr-Spock - All your .sigs are belong to us - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040721203105.GA55687>