Re: emulate an end-of-media

Hi,

> I'm not sure wheher Martin is trying to create a dump that is a single
> logical volume split over multiple physical volumes or a multi-volume
> dump.

I want to make a real multi-volume dump over multiple media. Because
if I had only one big volume I'd  - in the worst case - have to insert
all media also if i want to recover only one file. And worser: I'd had
to read and decompress all media up to the end.
I could of cause use another backup backend but I think dump is one
of the best and reliablest backup mechanism. (Because it works on
inode-basis and not the user file-system level.)

> I suspect Martin is trying for the latter case - which has a number of
> advantages (like partial restores are much faster and a failed write
> can be retried on new media).  But it also has some gotchas.  The
> biggest one is that dump needs to be able to write past EOM (so it can
> record an end-of-volume block).

Oh - that are bad news. Do you know how many blocks/bytes dump needs
afterwards?

> [...]  But it does mean that
> your magic device needs to be able to return EOM to dump early enough
> that dump can record end-of-volume and the compressor can dump that
> block and any trailing state before it runs out of media.

And it makes the idea to convert a sigpipe to an EOM useless. I've
to think about that. (I thought I could just change dump in that
way that it handle a sigpipe like an EOM which would be very easy.)
Maybe I now have to implement the output byte counting of the script or
pipe specified by -P when -B was given.

Thak you,
   Martin L.


_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[e-mail]"