Read buffers show outdated content after write.

[scdbackup]

The originally intended title for this ticket was:

"tail" padding broken again in libburn

Well, it's not broken. I got fooled by the a problem which i know from early growisofs: reading after write without eject is merely fictional.

With growisofs i experienced kernel panics back in 2003 on such occasions.

I wrote a fat padding to a CD-RW and the following checkread gave me back the image without any padding. I had written this in the previous test, ejected and then had read it. Obviously the read buffers did not get discarded by libburn's write.

Kernel 2.4.21, ide-scsi, /dev/hdc-/dev/sg0 read from /dev/sr0

The classical workaround of growisofs was to eject and load the tray. Then came -use-the-force-luke=notray and - on my wish - -use-the-force-luke=noload . (Thanks again, Andy.)

I would undertake the endeavor to try to find out how Andy solved the problem. But he uses /dev/scd0 (resp /dev/sr0) and not /dev/sg0 .

Now i consider seriously to introduce that eject-load cycle into cdrskin with --luke_notray as (deprecated) inhibitor. ("noload" == "notray" -eject)

Anybody who can solve that problem by a little kernel call to devalue the buffers ? I hated the tray out-in of growisofs. Especially because scdbackup by tradition puts the tray out: out-in-2 seconds wait-out. Arghh !

[scdbackup]

The effect is not nicely reproducible, i fear (resp. i frolic).

I just burned a 125 MB ISO image over a 45 MB afio archive and the checkread sees the complete new ISO. My box has 1 GB of RAM and usually can buffer 45 MB between two CD reads. This time the drive started to blink immediately when i started reading.

So the problem might be restricted to very small tracks. Whew.

[scdbackup]

Damn. I cannot reproduce it for now.

It was there. I still see the commands and replies in the terminal window. Now it is gone. A Heisenbug.

[scdbackup]

First a legal statement: I did not try to exploit Murphy's law. I took a gift from it, as i often do.

After a *small* CD read the next burn result wether small or not gets visible not before eject and reload (or maybe some long waiting time for the buffers to become thrown out of RAm on their own).

The receipe to reproduce is:

$ dd if=/dev/zero bs=1M count=1 | ../test/libburner --drive /dev/sg0 --burn_for_real --blank_fast --stdin_size 1048576 -

$ wc /dev/sr0

0 0 1355776 /dev/sr0

(resp. 1048576 if not with upcoming default padding in libburner)

dd if=/dev/zero bs=1M count=1 | ../test/libburner --drive /dev/sg0 --burn_for_real --blank_fast --stdin_size 2000000 -

$ wc /dev/sr0

0 0 1355776 /dev/sr0

$ eject /dev/sr0

$ wc /dev/sr0

0 0 2308096 /dev/sr0