Re: Ext2fs and hashed table.

Torbjorn Lindgren (tl@funcom.com)
Sun, 15 Jun 1997 20:35:08 +0200 (MDT)


On 15 Jun 1997, H. Peter Anvin wrote:
> Followup to: <m2afkt4o28.fsf@forest.nuthouse.au>
> By author: Peter Moulder <reiter@netspace.net.au>
> > Harald Koenig <koenig@tat.physik.uni-tuebingen.de> 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?

Because:

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
properly...

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
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.