Skip site navigation (1)Skip section navigation (2)
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>