[Libburn] Re: Condensed list of problems with libburn
scdbackup at gmx.net
scdbackup at gmx.net
Tue Jan 3 04:08:10 PST 2006
Hi,
> Hmm, I probably should've replied solely to this email. oops. :)
Yes, we are terribly asynchronous in our conversation :))
I believe you have read all my mails now. So i begin to reply.
For the open topics :
----------------------------------------------------------------------------
1) False reports of drive and media status after load:
> > The first burn_disc_erasable() says it is
> > appendable. The second try says it is full.
> > I reload the CD-RW. Now it is reported blank.
>
> > The drive speed is 8448 on unloaded tray and
> > 2112 on loaded tray.
> > (On my 2.4.21 system its 4234 and 1764.)
> >
> > It looks like the drive would need more time
> > to make up its mind after loading.
>
> Your drive returns different speed capabilities depending on which kernel
> you're using?
No. This rather depends on the writer device.
The 2.4.21 system hosts the LG DVDRAM and the 2.4.4 system
has the LITE-ON CD-RW.
Sorry for being unclear with that.
> > The following call returns confusing values with 4x and 4x-12x CD-RW
> > ret= burn_drive_get_write_speed(drive);
> > printf(" burn_drive_get_write_speed = %d\n",ret);
> >
> > yields directly after loading the
> > burn_drive_get_write_speed = 4234
> > and on second try
> > burn_drive_get_write_speed = 1764
> >
> > With kernel 2.6.14 and LITE-ON burner :
> > 8448 resp. 2112
> >
> > No difference between 4x and 12x media.
>
> Absolutely bizarre. Those values should be returned directly from the
> drive and independent of kernel version.
>
> I'll dig around, but since I don't have 2.4.x here, I hope you don't mind
> if I bounce potential fixes off you... :)
The problem is even more obvious on the 2.6 based system.
There it does not only report wrong speed but wrong media.
I meanwhile employ a complicated dance of
init+scan(loading) - grab - release - grab - release - finish - init+scan - grab - release - grab
in order to get plausible results for my partial -atip emulation
which detects the media type and its possible maximum speed.
----------------------------------------------------------------------------
2) Ejection of media does not work.
> > burn_drive_release(drive,1) does not eject
> > the drive. (Like with my ide-scsi 2.4.21)
>
> This is puzzling. :(
>
> I'll see if I can duplicate it here. My lite-on drive should be very
> similar to yours.
As clarification: burn_drive_release() does not eject /dev/sg0
or /dev/sg1 on 2.4 kernel systems with ide-scsi and it does not
eject /dev/hdc on a 2.6 kernel without ide-scsi.
----------------------------------------------------------------------------
3) libburn versioning.
> > Is there any means to determine at compile time the
> > version of the libburn header and at run time a comparable
> > version string ?
> > If not : i propose [..]
> > #define BURN_LIBRARY_VERSION "0.2"
> > #define BURN_SNAPSHOT_DATE "2005.12.08.203854"
> > void burn_version_strings(char library_version[80],
> > char snapshot_date[80])
> >
> > The macros would help to adapt to changes in libburn.h
> > if one links directly the .o files.
> > The macros together with function would allow to check
> > compatibility at startup and to issue version messages.
>
> Sorry to be dense, but can you explain to me why this is useful?
At compile time i currently have to use own macros like
#ifdef Cdrskin_libburn_cvs_A51208_tS
written_total_bytes= ((double) p->sector)*2048.0;
#else /* Cdrskin_libburn_cvs_A51208_tS */
written_total_bytes= ((double) p->current_sector)*2048.0;
#endif /* ! Cdrskin_libburn_cvs_A51208_tS */
which i have to set externally via the compiler command.
> The last thing in the world I want is a bunch of wacky ifdefs so that one
> app will run against 12 different versions of the library, and runtime
> checks would be even more gruesome...
An absolutely stable API would make versioning technically obsolete,
indeed. But that might be too big a wish :))
I could need run-time version info for some messages like
$ cdrskin -scanbus
...
Using libburn version '0.2.ts'.
scsibus1:
1,0,0 0) 'HL-DT-ST' 'DVDRAM GSA-4082B' '?' Removable CD-ROM
> I can see how a run time version string would be nice for weeding out
> already-solved bug reports. Other than that, why does the app need to
> know what version it's using?
I think the bug report issue is important.
The enhancement would not cost much and we application programmers
could invent some use for it.
----------------------------------------------------------------------------
4) New structure members in struct burn_source
> > burn_source.recent_bytes tackles the problem that on error read(2)
> > is free to either
> > return -1 immediately
> > or to
> > return a partial buffer and report the error on the next call.
> > ...
> > So if libburn wants partial buffers on error (note: this is not
> > about EOF) then it should handle in sector.c:get_bytes()
> > an eventual non-zero src->recent_bytes as valid data before
> > it starts its padding.
>
> My current thinking is that we just shouldn't return short from the source
> function, unless it's EOF. The source can block (and the drive can
> underrun...)
If read() encounters an error while having already buffered
some bytes (an incomplete sector) there remains the question
what to do with those buffered bytes.
burn_source.recent_bytes allows libburn to decide wether it
will forward those bytes to the burner or wether it will
discard them.
Of course, if you decide to always discard an incomplete
sector on error (not on EOF), then this feature is obsolete.
> > burn_source.delivered_bytes is just an idle counter yet.
> > I believe that any good data source object should have such a
> > counter of total bytes. Applications for that will emerge.
>
> We've already got the burn_progress struct and burn_drive_get_status...
>
> Is this just two ways of viewing nearly identical information?
It is viewing correlated information at two different points
of the processing pipeline.
burn_source.delivered_bytes would count the bytes read from a
particular source while burn_progress and burn_drive_get_status
reflect the status of the write process (for all sources).
But i don't insist in this.
If i hadn't implemented burn_source.recent_bytes as a workaround
for partial sectors after error then i would not have touched
that source-counter topic at all.
----------------------------------------------------------------------------
5) Arbitrary data formats from arbitrary sources
> I think I prefer a new constructor with a "size hint", and if it's
> non-zero it'll prevent any checks of the file size.
>
> Also, it might be best to force the application to open the files, and
> just always expect file descriptors.
>
> Would this work for you?
Yes.
Meanwhile cdrskin got a fifo buffer which is installed between
actual source and burn_source like this :
- open source fd
- create pipe(2)
- attach source fd and pipe inlet to the fifo
- attach pipe outlet to struct burn_source (via a "#N" pseudo file name)
So a constructor with parameters "size" and "fd" would be well
suited for me.
(Although pipe(2) is not the most effective transfer method
it does only impose tenths of a percent load on my AMD 2600+
when burning with 10x speed.)
> > http://lists.freedesktop.org/archives/libburn/2004-November/000232.html
> >> I'll write that if there's interest.
> > Was there interest ?
> > Did you write something already ? (Did i miss it ?)
> It has not been done.
> Is there now interest? :)
Better than that.
I wrote it as my second patch to libburn :))
> > Any archive format that is generated by a single pass over the
> > file system tree will not be able to predict its size early.
>
> I hadn't thought of the hideous possibility of sending a .tgz or something
> as mode-1 data.
Imagine this hideousness :
a ISO9660 image of 300 MB
+ a marker tag that announces the following data
+ a block permuted copy of the 300 MB ISO image
+ a checksum tag
+ a block checksum list
+ some application provided padding
Any program that is naive enough to interpret the header of
that (perfectly mountable) ISO image will be quite surprised
by the following redundancy data.
growisofs reports 201% work done.
You have to expect us applicators to do such things. :)))
(That CD may be produced in three identical copies and
after years of deterioration you can merge all three double
copies into one that is free of errors ... if only one of
each six block copies (a 64 kB) can be read correctly.)
> > Is there any specification for the contract between burn_source
> > and burn_source.read() ?
> > In the API docs i only find this description:
> > int read(struct burn_source *, unsigned char *buffer, int size)
> > Read data from the source.
> > If i design my own Yoyodyne-read() what would it have to do
> > so it doesn't break libburn ?
>
> Never try to put more than "size" bytes into "buffer".
Ok.
> Other than that, you can do most anything you want in there. But try to
> do it before the drive's buffer depletes. :)
Would there be interest in including my fifo into libburn ?
It is a separate (C language) class which now works in cdrskin,
as standalone stdin-to-stdout filter and within a program of mine
that feeds growisofs. (It improves average on-the-fly DVD speed
for ISO-9660 from 3.4x to 3.9x.)
That fifo has been tested for up to 10 TB (lasted 16 hours).
> I think a return of -1 should mean there are no more bytes to be found
> here, ever.
0 for EOF and -1 for error should be ok.
But there is still the issue of a last incomplete sector
buffer after an error. You should specify what a reader
is supposed to do with such data.
It should also be defined that only the last buffer of
a read stream may be returned incomplete.
----------------------------------------------------------------------------
6) Protection of normal operations against ill drives
> > So this is an evil user trap:
> > crw-rw-r-- 1 root disk 21, 0 Sep 23 2003 /dev/sg0
> >
> > There might be valid sysadmin reasons for such a setting.
> > Then it prevents the use of any other drive, too.
>
> I think I've fixed this. The fix is to disallow the use of any device
> with such permissions. I don't believe this breaks any valid
> configurations.
How about my proposal of an optional whitelist which excludes
any other devices from enumeration and scanning ?
There is not only the r-but-not-w problem but also a problem
with my ill DVD-ROM if it has DMA enabled on kernel 2.6.
Such a piece of hardware can be a real obstacle to libburn.
The whitelist would avoid such interference in most daily usage
situations.
I can hardly do user-safe operation of a backup tool without a
method to isolate from any other drives than the one used.
On the other hand i would like to use a future official version
of libburn rather than my patched one.
----------------------------------------------------------------------------
7) Preparation for future challenges
> > I still believe there should be a change of the data type for
> > source size from int to off_t or double .
>
> I'm not a fan of double for this application.
> How about uint64_t from stdint.h? (I think it's c99, is libburn ever
> going to run on a non-c99 platform?)
Given the quite narrow target scope of libburn any modern
Linux data type would be ok.
My own applications are written for maximum portability
so i do not even use ANSI-C but K&R style.
double is a usable alternative to more proprietary types
if one can stay within the resolution of the mantissa
(50+ bits).
If i have to rely on extra large numbers which need a
resolution of 1, then i use a selfmade 90bit class.
----------------------------------------------------------------------------
8) Padding.
> > The following call does not cause padding to be appended
> > int padding= 52428800;
> > burn_track_define_data(tr,0,padding,1,BURN_MODE1);
> >
> > Actually parameter "tail" is ignored in burn_track_define_data() .
>
> Oops. Not only is it not defined, but it's not honoured in the sector
> generation code. heh.
>
> Neither is the offset option.
>
> oh dear.
>
> Should be fixed in cvs... I haven't tested it myself yet, will try to do
> that tomorrow.
That would be fine.
K3b obviously does not close the pipe inlet when all writing
is done. My workaround for padding then would wait infinitely
for the announced surplus data to come.
To my luck, K3b does neither employ -pad nor padsize= .
But if i add padsize=300k to K3b's cdrecord options
then the run does never end.
----------------------------------------------------------------------------
9) Failure to prevent burning by burn_write_opts_set_simulate()
> Does it prevent burning on your lite-on? Is cdrecord capable of
> simulating on that drive (in SAO or RAW)?
>
> It's possible that the drive doesn't support simulation in the requested
> write mode.
I will introduce a -dummy option into cdrskin and try.
----------------------------------------------------------------------------
10) The mail riddle.
> By the way, apparently my ip address is listed as dynamic in "SORBS", so I
> can't send email to gmx.net directly.
>
> Sometimes I think anti-spam solutions are worse than the cure. Oh well.
Yes, they are.
I prefer to read spam over being excluded from communication.
It is still weird:
- i receive my own posts from libburn at lists.freedesktop.org
- i do not receive yours or others.
(I got the Cc:scdbackup at gmx.net from Dana and a mail from Tiago,
but not their messages from the list.)
- i am not aware of any other people having problems t reach me.
(See Tiago's and Dana's Cc:)
- Tiago's message does not appear in the libburn archives :
Date: Mon, 26 Dec 2005 15:33:02 -0100
From: Tiago Cogumbreiro <cogumbreiro at users.sf.net>
To: "scdbackup at gmx.net" <scdbackup at gmx.net>
Cc: libburn at lists.freedesktop.org
Maybe some day i will learn why this happens.
-----------------------------------------------------------------------------
Whew.
Please give me a note when your changes in the CVS are done.
I will then apply my waiting whitelist patch and test wether old
problems are gone.
Next i will post that whitelist patch in the hope you accept it.
(It has proven to be mighty convenient for me.)
Have a nice day :)
Thomas
More information about the libburn
mailing list