[ale] Anyone here who is good with kernel programming?

[Jim Kinney]

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.

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.

On Fri, Feb 12, 2010 at 4:20 PM, Michael B. Trausch <mike at trausch.us> wrote:

> On 02/12/2010 02:26 PM, Ed Cashin wrote:
> > My intuition is that your problem is best solved in userspace,
> > but if I'm wrong, there should be a specific reason---something
> > that you can't do in userspace, like using some drive registers
> > that are not accessible outside the kernel.
>
> It is currently a veritable PITA to do things like get the capacity of a
> blank optical disc in userspace, which is the cornerstone of being able
> to robustly deal with certain types of users.  Granted, it's an ideal
> solution that I am going after, and I might have to kludge something
> together that is a _very_ temporary solution, but this whole process
> should be no more complex than:
>
> # tar --create --multi-volume --file=/dev/sr0 /home
> Prepare volume #2 for `/dev/sr0' and hit return:
> Prepare volume #3 for `/dev/sr0' and hit return:
> Prepare volume #4 for `/dev/sr0' and hit return:
> Prepare volume #5 for `/dev/sr0' and hit return:
> # _
>
> Or even:
>
> # do-home-backup
> Prepare volume #2 for `/dev/sr0' and hit return:
> Prepare volume #3 for `/dev/sr0' and hit return:
> Prepare volume #4 for `/dev/sr0' and hit return:
> Prepare volume #5 for `/dev/sr0' and hit return:
> # _
>
> (where do-home-backup is a script that simply runs the command above,
> because that's easier for a client to remember than the tar command).
>
> > And if you can do it in userspace, rejoice!  It is much more
> > challenging to program in the kernel than in userland.
>
> Oh, yeah.  I'd love it if there were a way to do this in userland with
> tar.  I _can_ think of a way to do it in userland, kind-of-sort-of, but
> it would no longer involve using tar---what I'd have to do instead is
> probably write a special-purpose, non-portable program that writes
> multi-volume tar archives to optical media under Linux.  However, given
> that the driver already permits 'dd' to write to DVD-RAM media, I have
> to wonder how difficult it would be to permit it to write to non-RAM
> media as well, and just prohibit anything other than sequential writing
> to blank media.
>
> > The kernelnewbies mailing list is a great place to ask questions
> > like this, and there are some real experts that frequent that
> > list from time to time.
>
> I will have to check that out if trying packet writing does not work (or
> work well enough).  Thanks for the pointer!
>
> > When you described the userland strategy of using multiple
> > pseudoterminals, it sounded like yours might be a job for
> > expect.  But I'm not really familiar enough with multi-volume
> > tar archives and wodim to say.
>
> I think expect would be able to do it.  I could, I think, do it with
> bash, dialog, expect, tar, and wodim.  However, it would be a rather
> rigid/fragile solution and I would see that as only a very short-term
> thing to be replaced with a better and more efficient solution.  Why
> involve 5+ processes when the job really should only require a single
> process doing a single thing?
>
> I do think that the right place for the fix is in the kernel and to only
> have to lightly patch tar to learn how to determine the media size.
>
>        --- Mike
>
> --
> Michael B. Trausch                    Blog: http://mike.trausch.us/blog/
> Tel: (404) 592-5746 x1                            Email: mike at trausch.us
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
-- 
James P. Kinney III
Actively in pursuit of Life, Liberty and Happiness
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100212/08d2ba4b/attachment.html