emulate an end-of-media

Alex Zbyslaw xfb52 at dial.pipex.com
Mon Feb 25 22:00:48 UTC 2008


Mike Meyer wrote:

>On Mon, 25 Feb 2008 21:19:33 +0100 "Martin Laabs" <martin.laabs at 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=... -
>>>      
>>>
>>
Why compress?  It's ancient technology and will be vastly outperformed 
by gzip (and bzip2 but that's slower).

>>>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.
>  
>
Are there not (at least) two more alternatives?

    1) Add gzip/zlib support to dump.  That would seem easier than new 
devices.  Then -a would just work.

    2) Instead of using cdrecord directly you have a wrapper which 
"emulates" the dump -a behaviour by writing 650/700Mb of data using 
cdrecord then prompting for the next cd.  You don't close the pipe, and 
dump should just block waiting for your "device" to be ready.  Might 
have trouble accessing /dev/tty - not sure.

--Alex



More information about the freebsd-hackers mailing list