From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 25 20:46:10 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 BD6BA16A411 for ; Mon, 25 Feb 2008 20:46:10 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 5863013C44B for ; Mon, 25 Feb 2008 20:46:09 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 88565 invoked by uid 1001); 25 Feb 2008 20:44:57 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Mon, 25 Feb 2008 15:44:56 -0500 Date: Mon, 25 Feb 2008 15:44:55 -0500 To: freebsd-hackers@freebsd.org Message-ID: <20080225154455.4822e72a@bhuda.mired.org> In-Reply-To: References: Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer 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:46:11 -0000 On Mon, 25 Feb 2008 21:19:33 +0100 "Martin Laabs" wrote: > 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=... - > > Unfornunately this does not work as you expect. Actually, it works exactly as I expect. It just doesn't do what you need. I propose you fix that rather than write a magic signal propagating device. > 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) No, a pipe has a SIGPIPE signal. The fix (assuming it will work with the multi-process dump design) would be to make dump treat a sigpipe like an EOM. > and the -B option will limit the input data only: Correct. But that behavior is less desirable than fixing this to do what you want. > > > 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. While you're proposing a magic device that catches sigpipe, and delivers an EOM to make dump -a happy. I'm proposing that dump catch the sigpipe, and treat it like an EOM if it has -a. This may be non-workable, in that you have to be able to tell if it was the -P process or a slave process that generated the sigpipe, but I think it's the best solution. > 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. That same script should work with both fixes. > > 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. Yup. And as I wrote, fixing this is desirable. I think fixing -a is better, but this would be nearly as good. This would involve rewriting your block-counting script in C inside dump, and having that work on the output of the -P process. > 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? The last time I provided patches to dump (fixing -w/-W so they didn't skip every other day), it took longer for it to get MFC'ed than it did to get the patches committed in the first place. In the interim, I kept a patch file in my home directory, and would just reapply the patch after doing updating the source tree. Neither one was a major problem. If you agree that this is the better solution (if not - well, that's your choice), then don't let worries about having to maintain patches outside the tree stop you from doing it. There are tool sets for dealing with such available, either in ports or via google (haven't needed it for a while, so I'd have to look). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.