Date: Mon, 25 Feb 2008 15:44:55 -0500 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: freebsd-hackers@freebsd.org Subject: Re: emulate an end-of-media Message-ID: <20080225154455.4822e72a@bhuda.mired.org> In-Reply-To: <op.t63j2veq724k7f@martin> References: <op.t63j2veq724k7f@martin>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2008 21:19:33 +0100 "Martin Laabs" <martin.laabs@mailbox.tu-dresden.de> 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).
<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?20080225154455.4822e72a>