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

[Michael H. Warfield]

On Fri, 2010-02-12 at 14:14 -0500, Michael B. Trausch wrote: 
> I'm finding myself (again!) running into the annoying limitation of not 
> being able to write directly to optical media without third-party 
> programs.  What I'd like to do, even if upstream *never* accepts it, is 
> to modify my local kernel (and perhaps patch GNU tar, though that would 
> be the easy part) to permit something like the following on Linux systems:

> # tar --create --multi-volume --file=/dev/sr0 /home

It may be somewhat sub-optimal performance-wise, not having done this I
really can't say, but have you tried packet writing?  That's what the
udf file systems use on CD-RW, DVD+-RW.  Now, performance of RW media is
never as good as R media and, iirc, packet writing does add some
overhead.  But, then again, if your overriding concern is to be able to
write straight to the media, this would be the way to do it.

Some more information is here:

http://www.mjmwired.net/kernel/Documentation/cdrom/packet-writing.txt

But that's really just the "packet-writing.txt" file in the kernel docs.
Might give you some clue where to start.  Seems like everything you
need, like the "pktcdvd", is there already in the Fedora kernels, at
least.

Here's another article on it:

http://www.g-loaded.eu/2005/11/10/packet-writing-on-cdrw-and-dvdrw-media/

And you'll need the udftools installed.

No kernel hacking required...

> Currently, to accomplish the same task, one has to do something like this:
> 
> # mkfifo backup_stream
> # tar --create --tape-length=683593 --file=backup_stream /home
> 
> And then in another shell (for every single volume):
> 
> # wodim -tao backup_stream
> 
> Which generates lots of warnings and the like, and is just completely 
> not useful when someone just has to come in, run a backup, and go away 
> without any knowledge of Unixy systems in general.
> 
> There are several problems with this method:
> 
>    * All media must be the same size (or at least, no smaller than the
>      --tape-length specified on the command line)
>    * There is necessarily some wasted space on the backup media because
>      there is no way to detect the amount of data that will actually fit
>      and then pass that back to tar, so the smallest expected disc size
>      must be given to tar.
>    * wodim or growisofs must be run once for every disc in the set,
>      instead of just changing discs and telling tar that it should be
>      able to do a new disc.
>    * If the human doing the backups is only reliable enough to read
>      "Prepare volume #x for `backup_stream' and hit return:" and do that,
>      then you would have to have a program managing the burning process
>      in a pty.
> 
> Without modifying the kernel, it would seem that the best solution to 
> the entire problem would be to write a program that allocates two pty 
> pairs, runs tar in the first pty and runs wodim or growisoimage in the 
> second one, hiding all the detail away so that it is comfortable. 
> Furthermore, it could then count the directories and such and show a 
> progress indicator on the tar operation and on the per-disc burning 
> process.  However, I think I'd rather just be able to use tar and be 
> done with it.
> 
> On to the question, then:  Does anyone know what would be required to 
> implement sequential write access in the kernel?  The way that I would 
> envision it, it only needs to do two things:  Write sequentially to a 
> disc when it is already purely blank, or reject the write if there is 
> already data on the media (that is, I would be fine without the ability 
> to append to discs).  I would also be fine with the kernel only 
> guaranteeing success if the data stream is constant.  That would also 
> imply that there should be a means, perhaps via an ioctl() operation, to 
> set the speed on the drive if the stream is known to be slower than what 
> the drive's write speed is, and also that the kernel should take care of 
> some form of buffering.
> 
> The major problem is that I don't have the slightest clue where I would 
> make such changes, nor do I know the first thing about making them at 
> that level.  I'd be able to write a userspace solution if I had to, but 
> I'd rather not.
> 
> Any advice or pointers?
> 
> 	--- Mike
> 

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20100212/4106e3d8/attachment-0001.bin