On Wed, Aug 02, 2006 at 05:33:40PM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote: > >The "cheap" solution is to handle it purely on > >extract: Detect blocks of zeros when restoring > >files and seek over them. > > The downside is that you wind up with a sparse file whether or not you > wanted one.
No, you wind up with a sparse file if you specify the "-S" option to tar. If you didn't want one, don't specify the option. > Actually, the only real solution to copying sparse files is to add > a system call that can return a map of holes. This would neatly > address the "needs two passes" problem with tar. You don't need two passes-- you advance the file pointer whenever you detect a block of zeros. Note: care must be taken to only do this for newly-created or otherwise truncated files, otherwise the skip ahead wouldn't work. > As a general comment (not addressed to Tim): There _is_ a downside > to sparsifying files. If you take a sparse file and start filling > in the holes, the net result will be very badly fragmented and hence > have very poor sequential I/O performance. If you're never going to > update a file then making it sparse makes sense, if you will be > updating it, you will get better performance by making it non-sparse. Agreed, with a minor correction/elaboration. By "updating" you mean specifically "updating but not appending". And another note: a good way to defragment a file is to sequentially copy it. (The "best" way is to copy the file to a new filesystem, that way you guarantee the blocks allocated to the file are contiguous.) -- Rick C. Petty _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
