Re: compression in dump(8)
On 2016-05-02 2:29 PM, Robert Elz wrote: I do gzip -d < /path/do/mydump | restore -if - all the time, it works just fine. And that's because dump/restore were built to work with tapes, where backspace/rewind is evil. This is why the multiple passes during dump – it writes a table of contents at the start of the dump set so it knows where to find everything on the tape(s). (More or less.)
Re: compression in dump(8)
On Mon, 2 May 2016, Christos Zoulas wrote: > It does; the dump format puts the directory info first so that it can > restore the stuff you selected in a single pass (it does not need to > seek backwards). Gotcha. Sorry for piping up about something that already works then! I'll be sure to try it next time I need to. > Of course if you select some, restore, try to select some more, > restore... It will not work since it will need to seek backwards then. Understood. That makes good sense. > Remember all this stuff was designed with tapes in mind, not random > access devices. Roger that. -Swift
Re: compression in dump(8)
In article, Swift Griggs wrote: >On Mon, 2 May 2016, Christos Zoulas wrote: >> Doesn't that work? zcat dump.gz | restore -f - > >Yes it does. What I don't believe will work is this (interactive restores >when I only want to restore a few files): > >restore -i -f /path/to/mydump It does; the dump format puts the directory info first so that it can restore the stuff you selected in a single pass (it does not need to seek backwards). Of course if you select some, restore, try to select some more, restore... It will not work since it will need to seek backwards then. Remember all this stuff was designed with tapes in mind, not random access devices. christos
Re: compression in dump(8)
On Mon, 2 May 2016, Christos Zoulas wrote: > Doesn't that work? zcat dump.gz | restore -f - Yes it does. What I don't believe will work is this (interactive restores when I only want to restore a few files): restore -i -f /path/to/mydump -Swift
compression in dump(8)
I notice that the dump command in NetBSD doesn't feature the use of any internal compression. If one compresses the dump file, then you can't use it as the basis for a restore. Is that because the compression functions aren't in libc (ie.. they are off in libz or liblzma) ? Perhaps it's just a matter of someone doing the work ? It'd be a big help for admins who want to be able to use a modern compression algorithm without having to uncompress the dump to use it. I for one, would use it on all my systems. -Swift