Re: Ext2fs and hashed table.

Torbjorn Lindgren (
Sun, 15 Jun 1997 20:35:08 +0200 (MDT)

On 15 Jun 1997, H. Peter Anvin wrote:
> Followup to: <>
> By author: Peter Moulder <>
> > Harald Koenig <> writes:
> >
> > > I'd say "tries to handle"... gnu-tar can't distinguish between
> > > allocated blocks all zero and sparse holes. in case where it's
> > > important that some areas are really allocated, gnu-tar may break
> > > your files. might not be a common problem but tar just can't deal
> > > with sparse files perfectly; dump/restore can...
> >
> Why would that matter?


1. The files may well not *fit* on the disk if they aren't sparse! Take a
couple sparse 2GB cores, which really take less than 100KB each, handled

2. The file might *have* to be sparse, otherwise it won't work (rather
uncommon, but it do exist).

> I would argue that dump can't deal with *ANY* file perfectly, since it
> (in the typical configuration) is committing the utter no-no of
> reading a non-quiescent r/w mounted filesystem from the raw block
> device.

At least it's *tries* to handle them, which is more than I would claim
tar/cpio et al tries to do :-) Yes, another approach would be better, but
there are lots of cases where tar/cpio isn't anywhere near enough.

There *are* reasons why commercial UNIX backup systems doesn't usually use
the 'read the raw-device' approach (one of them is the porting nightmare),
but on the other hand the one's I know of does handle sparse files, it's
really a necessity for serious backups.

Wonder what it would take to make Legato (Networker) or Spectra Logic
(Alexandria) to create a backup client for Linux. Both support SCO after
all. The best would be to get them to port the Server too, but that might
be considerably harder :-)

Torbjörn Lindgren
If Santa ever DID deliver presents on Christmas Eve, he's dead now.