From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 25 20:19:39 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D55A616A412 for ; Mon, 25 Feb 2008 20:19:39 +0000 (UTC) (envelope-from martin.laabs@mailbox.tu-dresden.de) Received: from mailout1.zih.tu-dresden.de (mailout1.zih.tu-dresden.de [141.30.67.72]) by mx1.freebsd.org (Postfix) with ESMTP id 654F913C469 for ; Mon, 25 Feb 2008 20:19:39 +0000 (UTC) (envelope-from martin.laabs@mailbox.tu-dresden.de) Received: from rmc67-31.zih.tu-dresden.de ([141.30.67.31] helo=server-n) by mailout1.zih.tu-dresden.de with esmtp (Exim 4.63) (envelope-from ) id 1JTjnS-0002fJ-Tc for freebsd-hackers@freebsd.org; Mon, 25 Feb 2008 21:19:38 +0100 Received: from martin (p5B0ED680.dip.t-dialin.net [91.14.214.128]) by server-n (Postfix) with ESMTP id 716DB100A092 for ; Mon, 25 Feb 2008 21:19:34 +0100 (CET) Date: Mon, 25 Feb 2008 21:19:33 +0100 To: "freebsd-hackers@freebsd.org" From: "Martin Laabs" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Message-ID: User-Agent: Opera Mail/9.25 (Linux) X-TUD-Virus-Scanned: mailout1.zih.tu-dresden.de Subject: Re: emulate an end-of-media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 20:19:39 -0000 Hi, On Mon, 25 Feb 2008 20:34:31 +0100, wrote: > 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=3D... - Unfornunately this does not work as you expect. Dump just takes its data an pass it to the script specified to -P. It does not grab the output of the script to count the data after- wards. This means the -a option does not work at all (because a pipe has no EOM-Signal) and the -B option will limit the input data only: $ dump -0 -B 100 -P 'dd' /dev/md4 > /dev/null DUMP: Date of this level 0 dump: Mon Feb 25 21:11:40 2008 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/md4 to child pipeline process DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 30022 tape blocks on 291.38 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] 200+0 records in 200+0 records out 102400 bytes transferred in 0.031908 secs (3209223 bytes/sec) DUMP: Closing child pipeline process DUMP: Change Volumes: Mount volume #2 DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") In contrast with: $ dump -0 -B 100 -P 'compress -c' /dev/md4 | dd > /dev/null DUMP: Date of this level 0 dump: Mon Feb 25 21:12:23 2008 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/md4 to child pipeline process DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 30022 tape blocks on 291.38 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing child pipeline process DUMP: Change Volumes: Mount volume #2 DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") ^C 59+1 records in 59+0 records out 30208 bytes transferred in 6.315456 secs (4783 bytes/sec) > Assuming that compress -c & cdrecord play nice (which your magic > device solution also requires) My solution can just close the pipe at the one "end" of the magic device which would be realy simple to implement in a script. Of cause cdrecord will indeet close the pipe when the media is full. But= I think the media will not be usable since there is i.e. just no more space for finalisation of the dvd. But this is not a big probleme since I can use my "count compressed data and close stdin after is reaches limit x"-script. > 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. Yes - this would be the best solution at all. But as I wrote - the -B option only counts the data thats thrown out to stdout from dump and doesn't fetch stout again. Changing this behaviour of dump would break the backward compati- bility. (However - I could introduce a new Option i.e. -C for compress := -) But I worrie about updates with such a modified dump because I would have to patch the original dump every time after I'd updated my system. How hard is it to get those a change into the CORE-Tree when coded and tested well? Thank you, Martin L.