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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
