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"><<a href="mailto:mike@trausch.us">mike@trausch.us</a>></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>
> My intuition is that your problem is best solved in userspace,<br>
> but if I'm wrong, there should be a specific reason---something<br>
> that you can't do in userspace, like using some drive registers<br>
> 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'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' and hit return:<br>
Prepare volume #3 for `/dev/sr0' and hit return:<br>
Prepare volume #4 for `/dev/sr0' and hit return:<br>
Prepare volume #5 for `/dev/sr0' and hit return:<br>
# _<br>
<br>
Or even:<br>
<br>
# do-home-backup<br>
Prepare volume #2 for `/dev/sr0' and hit return:<br>
Prepare volume #3 for `/dev/sr0' and hit return:<br>
Prepare volume #4 for `/dev/sr0' and hit return:<br>
Prepare volume #5 for `/dev/sr0' and hit return:<br>
# _<br>
<br>
(where do-home-backup is a script that simply runs the command above,<br>
because that's easier for a client to remember than the tar command).<br>
<div class="im"><br>
> And if you can do it in userspace, rejoice! It is much more<br>
> challenging to program in the kernel than in userland.<br>
<br>
</div>Oh, yeah. I'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'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 'dd' 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>
> The kernelnewbies mailing list is a great place to ask questions<br>
> like this, and there are some real experts that frequent that<br>
> 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>
> When you described the userland strategy of using multiple<br>
> pseudoterminals, it sounded like yours might be a job for<br>
> expect. But I'm not really familiar enough with multi-volume<br>
> 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>