Date: Sat, 24 Jul 2004 06:13:46 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Daniel Lang <dl@leo.org> Cc: Peter Jeremy <PeterJeremy@optushome.com.au> Subject: Re: NEW TAR Message-ID: <4102608A.1030805@freebsd.org> In-Reply-To: <20040721151427.GC54664@atrbg11.informatik.tu-muenchen.de> References: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Lang wrote: > > I assume, that for any consumer it is totally transparent if > possibly existing chunks of 0-bytes are actually blocks full of > zeroes or just non-allocated blocks, correct? For most practical users, it is totally transparent, and in practice, "sparse file storage" in tar files is purely a compression technique. However, there are unusual cases both directions that need to be considered: If you don't restore a sparse file as a sparse file, you risk running out of disk space. If you restore a non-sparse file as a sparse file, then the file will be slower to write to (because the OS has to allocate space and because the file storage will be more fragmented). Also, there will be applications that do not handle "disk full" errors when they try to write to the middle of an existing file. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4102608A.1030805>