[Libburn-hackers] Re: Revival! And also question about burn_drive_scan with busy drives

Thomas Schmitt scdbackup at gmx.net
Sat Apr 26 03:11:35 CDT 2008


> >  That would be API call
> >   burn_preset_device_open(0, 0, 0);
> >  but be warned that this might be a bad idea.
> Ok, so that's not what I want to do then :-)

I would advise you to get the drive list at a time
when all drives are idle and to store it for later
use (when the drives potentially are busy).

E.g. as a separate GUI option "Assess Drives"
which gets run only when the user is sure that
no burns are going on.
(A counterpart to cdrskin --devices or -scanbus)

For a first overview of drives you might need
to be superuser anyway. My SuSE 10.2 gives the
desktop user access to the drives via ACLs set
at boot time. All my ealier systems needed
adjustments of rw-permissions in order to allow
normal users to open drive device files.

> It's too bad I don't have two drives to actually see if I would screw
> up my burn ;-).

A single drive is enough. You only need two programs
which compete about access to it.
- burn a CD-RW with any of cdrskin, xorriso, wodim, cdrecord.
- run a rogue bus scan with cdrskin:
   cdrskin --drive_not_o_excl --devices

Possibly you will have to do more than one of
the --devices runs to see a failure of the
ongoing burn run.
But even if it does not fail on your system
it is still prone to failure on others.

The failure should not happen with random access
media like DVD+RW, DVD-RAM, formatted DVD-RW, BD-RE.

It is well known with CD-R[W] and i expect it to
happen with DVD-R and unformatted DVD-RW.
That is because burning these media brings the drive
into a long lasting intermediate state, where most
other SCSI transactions are forbidden.
The operating system on the other hand has the idea
that SCSI transactions are self contained and do
not disturb other transactions which happen later
or have happened earlier.

This naivity explains why there are no CD-streaming
drivers for Linux: CD writing breaks their device
The only compliant model is "packet writing" on
formatted media. Thus DVD-RAM, DVD+RW and BD-RE
do have read-write support in the operating system.

> As far as I understand you, the initial burn_preset_device_open(0,0,0)
> could still disturb another ongoing burn, so what about the following:
> If libburn would return me those devices that are currently opened

It does not know whether a device address which is
banned for open(O_EXCL) is a CD/DVD drive or something
To recognize an optical drive, we have to open it for
reading and writing, have to examine its SCSI driver
status (which already might cause a  burn failure) and
have to send a few MMC commands to see how it reacts.

> then I can go and check through some means (i.e. by looking at
> /etc/mtab) that the reason for the O_EXCL is a mount.

Hmm. Yes. For that purpose it would suffice.
But you do not know whether you unmount a removable
hard disk or an optical drive.

For now you only get error messages out of the deeper
layers of libburn:
  cdrskin: scanning for devices ...
  cdrskin: SORRY : Cannot open busy device '/dev/sr1'
  cdrskin: ( Most recent system error: 16  'Device or resource busy' )
  cdrskin: ... scanning for devices done

It is possible but a bit cumbersome to evaluate those
messages by the application.
Direct all library messages to the message queue:
  burn_msgs_set_severities("ALL", "NONE", "...my_app_name...");
After running
obtain the pending messages from the queue
  while(1) {
    ret= burn_msgs_obtain(...,msg_text,...);
    ... interpret msg_text ...

> It'd be sweet if libburn could
> return me those devices though, because I don't know (or want to know
> :-P ) which ones I need to check...
If you decide for this gesture, then i can build
you an API call which provides lists of accessible
and inaccessible device files which could possibly be
optical drives.

But first you should make sure that this approach
really is free of severe problems due to the inability
to distinguish a /dev/hda hard disk from a /dev/hda
DVD burner. (Maybe the mount point "/media/..." can be
used as a criterion.)

> > ... hald-addon-storage ...
> I haven't had that problem yet, and I have that process
> running on my system...

This is what makes me wonder since about
one and a half year: we got too few bug reports
about that behavior. Even if i count those
which apply to other burn programs.

But i could reproduce it on a SuSE 9.3 quite reliably
and when i began to use my new 10.2 system it lasted
two hours before the first spoiled CD burn made me
search for the HAL processes which guard my drives.

> Hm, have you talked to the HAL guys? Seems like this really should be
> something that is necessary, if it's not currently implemented.

Ew. We have grabbed libburn from guys who are
good friends of the HAL guys.
And _I_ am not a friend of their concept.

Currently i am waiting for a user to have trouble
and to use him as excuse for starting a quarrel
with HAL.
That's because i can hardly say:
"Hey guys, i think you activities are counterproductive.
 But i want you to lean to my side and help to avoid
 a failure which hits far less people than it actually
(Cough, cough)

> On a side node, if libburn opens the device with O_EXCL, how come it
> is even possible to disturb the device then? Does Linux not enforce
> the exclusiveness correctly?

O_EXCL is strictly voluntary locking. Only if
all participants use O_EXCL they will be banned
from opening the device file.
And it works that way only on /dev/sg*, /dev/sr*,
/dev/scd*, /dev/hd* .

open(O_EXCL) itself has a long and winded history.
Originally it was a _part_ of a locking mechanism for
uucp : open(O_CREAT | O_EXCL) on regular files.
In that use case it only ensures that the desired file
does not exist yet and if so, it creates it in the same
atomar transaction.
This is standard Unix and documented in man 2 open.

Later the sg driver introduced a second meaning for
(pseudo-)SCSI device files. Here it is not associated
with O_CREAT and instead is a _complete_ locking mechanism.
Even later it wandered to the sr and the hd driver.
But as said before: one can well open such a locked
device file by just not using O_EXCL in the own call.

This O_EXCL on device files is particular to Linux
and not documented in the man page.

A special problem is that Linux mount attributes a
different meaning to O_EXCL than the burn programs do.
With mount, it is a hint that one should only read
and not write to that device.
With burn programs it is an urge to stay off at all.

I had a discussion with Ted T'so (himself !) about
that. We both tried hard to get his libblkid and
cdrskin coordinated safely - and failed.
Either libblkid would not be allowed to do what it
must do to potentially mounted devices, or cdrskin
was not really safe from libblkid interference.
We tested O_EXCL (already occupied by mount),
fcntl() (has loopholes), and lock files a la uucp
(too much system demands for libblkid which runs
already in half booted systems).

The kernel people are unwilling to acknowledge
the problem. I guess they use tapes for backup
and/or disable device groping automats.

If i had a real victim user, then i'd go around
and show his bleeding body. To LKML, HAL and
whomever might be concerned.
But all known victims so far just disabled HAL.


Have a nice day :)


More information about the Libburn-hackers mailing list