use tar to create multiple .tar.bz2 files sized to fit in an iso format. pipe the tar output through ssh to the CD burner. use a local process to convert to iso image and burn on the fly using userspace tools.<br><br>The issue will always be balancing network speed to burn speed. It would be best to have a way to make sure the file is received before the burn begins to avoid making a pile of coasters.<br>
<br><div class="gmail_quote">On Fri, Feb 12, 2010 at 4:20 PM, Michael B. Trausch <span dir="ltr">&lt;<a href="mailto:mike@trausch.us">mike@trausch.us</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 02/12/2010 02:26 PM, Ed Cashin wrote:<br>
&gt; My intuition is that your problem is best solved in userspace,<br>
&gt; but if I&#39;m wrong, there should be a specific reason---something<br>
&gt; that you can&#39;t do in userspace, like using some drive registers<br>
&gt; that are not accessible outside the kernel.<br>
<br>
</div>It is currently a veritable PITA to do things like get the capacity of a<br>
blank optical disc in userspace, which is the cornerstone of being able<br>
to robustly deal with certain types of users.  Granted, it&#39;s an ideal<br>
solution that I am going after, and I might have to kludge something<br>
together that is a _very_ temporary solution, but this whole process<br>
should be no more complex than:<br>
<div class="im"><br>
# tar --create --multi-volume --file=/dev/sr0 /home<br>
</div>Prepare volume #2 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #3 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #4 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #5 for `/dev/sr0&#39; and hit return:<br>
# _<br>
<br>
Or even:<br>
<br>
# do-home-backup<br>
Prepare volume #2 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #3 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #4 for `/dev/sr0&#39; and hit return:<br>
Prepare volume #5 for `/dev/sr0&#39; and hit return:<br>
# _<br>
<br>
(where do-home-backup is a script that simply runs the command above,<br>
because that&#39;s easier for a client to remember than the tar command).<br>
<div class="im"><br>
&gt; And if you can do it in userspace, rejoice!  It is much more<br>
&gt; challenging to program in the kernel than in userland.<br>
<br>
</div>Oh, yeah.  I&#39;d love it if there were a way to do this in userland with<br>
tar.  I _can_ think of a way to do it in userland, kind-of-sort-of, but<br>
it would no longer involve using tar---what I&#39;d have to do instead is<br>
probably write a special-purpose, non-portable program that writes<br>
multi-volume tar archives to optical media under Linux.  However, given<br>
that the driver already permits &#39;dd&#39; to write to DVD-RAM media, I have<br>
to wonder how difficult it would be to permit it to write to non-RAM<br>
media as well, and just prohibit anything other than sequential writing<br>
to blank media.<br>
<div class="im"><br>
&gt; The kernelnewbies mailing list is a great place to ask questions<br>
&gt; like this, and there are some real experts that frequent that<br>
&gt; list from time to time.<br>
<br>
</div>I will have to check that out if trying packet writing does not work (or<br>
work well enough).  Thanks for the pointer!<br>
<div class="im"><br>
&gt; When you described the userland strategy of using multiple<br>
&gt; pseudoterminals, it sounded like yours might be a job for<br>
&gt; expect.  But I&#39;m not really familiar enough with multi-volume<br>
&gt; tar archives and wodim to say.<br>
<br>
</div>I think expect would be able to do it.  I could, I think, do it with<br>
bash, dialog, expect, tar, and wodim.  However, it would be a rather<br>
rigid/fragile solution and I would see that as only a very short-term<br>
thing to be replaced with a better and more efficient solution.  Why<br>
involve 5+ processes when the job really should only require a single<br>
process doing a single thing?<br>
<br>
I do think that the right place for the fix is in the kernel and to only<br>
have to lightly patch tar to learn how to determine the media size.<br>
<div class="im"><br>
        --- Mike<br>
<br>
--<br>
Michael B. Trausch                    Blog: <a href="http://mike.trausch.us/blog/" target="_blank">http://mike.trausch.us/blog/</a><br>
Tel: (404) 592-5746 x1                            Email: <a href="mailto:mike@trausch.us">mike@trausch.us</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness         <br><br>