Date: Thu, 22 Jul 2004 09:02:44 +0200 (CEST) From: Harti Brandt <harti@freebsd.org> To: Daniel Lang <dl@leo.org> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: NEW TAR Message-ID: <20040722085729.O9549@beagle.kn.op.dlr.de> In-Reply-To: <20040721203105.GA55687@atrbg11.informatik.tu-muenchen.de> References: <Pine.GSO.4.61.0407211440210.28037@mail.ilrt.bris.ac.uk> <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> <40F963D8.6010201@freebsd.org> <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> <20040721203105.GA55687@atrbg11.informatik.tu-muenchen.de>
index | next in thread | previous in thread | raw e-mail
On Wed, 21 Jul 2004, Daniel Lang wrote: DL>To Harti: DL>I admit I don't know for sure, but to my understanding the handling DL>of the sparse file is done in the filesystem layer and not in the DL>application, right? Then all possible performance benefit on reading DL>a sparse file should be gained anyway. Regardless if the application DL>(the archiver) knows about the locations of the gaps or not.... I know of at least one application that does sparse file handling in the sense that it tries to create sparse file when the underlying FS supports it - that is my PDP11 emulator. I have even a special zcp utility that may re-sparse a file by copying it and looking for 0 blocks. It's not that p11 depends on the file system supporting sparse files - it just tries to use them if they are available. Again, for tar it's a matter of speed. Didn't Tim say that with the current sparse file info layout (gtar) he needs more than one pass over the file? hartihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040722085729.O9549>