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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040722085729.O9549>