dump -L

[illoai at gmail.com]

On 07/08/07, Victor Sudakov <sudakov at sibptus.tomsk.ru> wrote:
> illoai at gmail.com wrote:
> >
> > > > > > > Does nobody know the answer, or am I the only one experiencing the
> > > > > > > problem?
> > > > > >
> > > > > > I don't know the answer, but I get essentially the
> > > > > > same behaviour.  I have never seen any data loss,
> > > > >
> > > > > I gave an example below. The file "wins.dat" was not dumped. It is
> > > > > indeed missing from the tape.
> > > > >
> > > > > If this is not a data loss, what is it then?
> > > > >
> >
> > Not to perpetuate an argument for its own sake,
> > but I suppose I meant "data loss" to mean the loss
> > of files that _should_ exist, as opposed to files that
> > _could_ exist.  A fine line, but in my /laissez faire/
> > universe a quite salient one.
> >
> > As to whether wins.dat should exist is beyond me.
> > If you believe it should, then that would be data loss
>
> If it (or any other file) does exist in the filesystem, it should
> exist also in the backup. Otherwise we have a defective backup.

You are begging the question.

The functional definition of a live filesystem is one
in which you cannot guarantee the state to be
determineable across time.  Snapshots might make
it more likely, being faster, but they still have to work
in time*.  To put it another way: by the time any part
of the system knows the state of any part of the system,
it is wrong.

I would like to point out that I am not saying that
dump does not have a bug, but that this is not
evidence in and of itself for it.


*And no matter what anyone tells you, time is not
infinitely divisible.

-- 
--