Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2008 13:28:00 -0500
From:      Mike Meyer <mwm@mired.org>
To:        "Martin Laabs" <martin.laabs@mailbox.tu-dresden.de>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: emulate an end-of-media
Message-ID:  <20080225132800.7954bcf7@mbook-fbsd>
In-Reply-To: <op.t62ymri0724k7f@martin>
References:  <op.t62ymri0724k7f@martin>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2008 13:36:17 +0100 "Martin Laabs" <martin.laabs@mailbox.tu-dresden.de> wrote:

> Hi,
> 
> I'll write a script that back up my data on dvd-r and dvd-rams.
> (And some incremental backups also at some internet storage
> services.)
> Therefore I'd like to use dump. It is not too  hard to create
> dump-volumes with fixed size through the -B option. But now
> I'd like to use some sort of compression. (bzip2 seems far to be
> to slow. Maybe I'll use gzip or compress)
> However - with compression I can't use the -B switch of dump
> because I can't be sure about the compression ratio. This means
> I have to use the '-a' switch. With that switch enabled, dump
> starts a new volume after it detects an EOM signal.
> 
> Because dump itself does not support compression I have to
> build a pipe like that:
> dump -aL0 -f - /MYFILESYSTEM|compress -c|aespipe ...|cdrecord dev=... -
> This obvisouly does not work. I tried to wrote a script that
> close the pipe after the amount of compressed data reached
> 4.6GB. But if I close the pipe in that script dump aborts
> (because of the broken pipe) at all instead of just starting
> a new volume.

You might want to play with the -P option to dump. Your above could be
written as:

dump -aL0 -P 'compress -c' /MYFILESYSTEM | cdrecord dev=... -

Assuming that compress -c & cdrecord play nice (which your magic
device solution also requires), then all you need to do is make "-a"
DTRT when the pipe to it's -P option is closed. Dealing with buffering
could be an interesting problem in all these cases.

> What I'd need is a magaic pipe device that converts a ordenary
> close at the one side to an EOM at the other.
> Then I could do something like this:
> 
> dump -aL0 -f /dev/MyMagicDevice &
> dd if=/dev/MyMagicDevice bs=1M count=4600|./compress -c|cdrecord dev=... -
> 
> Before I try to write a kernel module that will do the
> job (I never wrote a freebsd kernel module before but
> I think it is some fun to learn that.) I want to ask if
> anyone see another solution for that problem. (Maybe
> patching dump - but I don't want to fudge in the CORE
> source.)

Your magic pipe device might be more generally useful, but I'm not
sure how many commands use EOM for anything at all. On the other hand,
having dump -a and -P work as expected (doesn't look like they do as
of 6.2) seems to be a good thing as well.

> PS: Splitting up the huge (maybe compressed) dump file (also in
> stream operation) is not a good idea beacause I'd need to insert
> all the media - even if I resore only a single file.

Well, if -B worked on compressed output, then  you could split it up
on volumes, which wouldn't be quite so bad. So add making -P and -B
play nice  together (again, they don't seem to as of 6.2) as a
possible solution.

	 <mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080225132800.7954bcf7>