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

[Michael B. Trausch]

On 02/12/2010 03:48 PM, Michael H. Warfield wrote:
> 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.

I haven't ever actually gotten packet recording to work (at least not on 
desktop systems) -- IME, it tends to screw up things pretty royally, 
especially with regards to programs' expectations that they would be 
able to use e.g., /dev/sr0 instead of /dev/pkt/pktcd0 or whatever it is 
that you have to use when that functionality is enabled.  So I can't say 
that I thought of it.  I'll try it again though to see if it has become 
functional enough to just install and use---that's really the key.

I did get it to *kind of* work once, but the write-performance was 
absolutely prohibitive, and it was moot anyway because the intent was to 
take the disc to a client's Windows system, but the Windows system 
couldn't read the UDF data anyway despite it being able to supposedly 
read that verison of UDF--that was quite some time ago, though.

What I'm really going for is a means to treat the drive like a big, 
sequential access, tape.  The *BSD systems do this, though with a little 
more functionality than I need.  For example, you can dd or tar directly 
to a CD/DVD/BD drive without any issues.  (That's even the preferred way 
to burn an ISO, just wget it and then dd if=file.iso of=/dev/drive, at 
least under FreeBSD).

> 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...

I have udftools installed for creating UDF filesystems on DVD-RAM media. 
  The interesting thing is that when DVD-RAM is in a drive, you *can* do 
things like "dd if=somefile of=/dev/sr0", but when a regular DVD+/-R is 
in the drive, you cannot.

The big advantage to having support for direct access to the media would 
be that tar could get the media's capacity pretty efficiently, and I 
could tell a random person, "to create a multivolume tar backup, just do 
this" and it'd be done.  I *think* (though I don't have a good way to 
check at the moment) that you can do similar things on BSD with just 
standard Unixy tools, and that'd really be my desire here---not to use 
anything that is outside of the normal stuff that'd be installed on a 
typical server system.

IOW, for *me*, I don't mind going through the process of:

  $ mkfifo burn-fifo
  $ tar --create --tape-length=683593 --file=burn-fifo /home

In one terminal window and then doing the actual burn command from the 
fifo in another.  For me, that's fine.  I do full backups every once in 
a while that way (though I use DVD instead of CD as the above command 
would be for).  But for someone who doesn't know why that works the way 
it does, they see it as needless procedure, and I can't say that I 
disagree.  I'd run FreeBSD on the target system if I could, just for 
that single and very useful feature.  However, it seems that I can't 
really do that; the client wants Ubuntu Server.

The other idea that I had, to write a small program that would hide 
these details, wouldn't be bad if it didn't have to be so complex and 
kludgey.  I'd much rather rely on having a custom kernel installed than 
on running different processes in different ptys and trying to 
coordinate all of that and *still* being fragile to the notion of the 
user having to be constrained to the same-size media for the entire 
backup run.  It's really too fragile a solution for the target environment.

	--- Mike

-- 
Michael B. Trausch                    Blog: http://mike.trausch.us/blog/
Tel: (404) 592-5746 x1                            Email: mike at trausch.us