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

David Mohr damailings at mcbf.net
Tue Apr 29 15:54:27 CDT 2008


On Sat, Apr 26, 2008 at 2:11 AM, Thomas Schmitt <scdbackup at gmx.net> wrote:
> Hi,
>
>
>  > >  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)

Hmm, I want to stay away from that too :-). Not considering the
practical problems that we are having, I want to be as automatic as
possible, and that means no more manually scanning for devices.

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

Good hint, I should probably add that to our warning when no drives
can be found. But the access problem exists for burning as well, so
this is a general issue.

>  > 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.
>  E.g:
>  - 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.

Hmm, I should try that out sometimes when I feel like wasting some media ;-).

>  This naivity explains why there are no CD-streaming
>  drivers for Linux: CD writing breaks their device
>  model.
>  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
>  > O_EXCL,
>
>  It does not know whether a device address which is
>  banned for open(O_EXCL) is a CD/DVD drive or something
>  else.
>  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.

True, although I might be able to get that info from hal which I would
hope acquired it during the boot process.

>  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
>   burn_drive_scan(...);
>  obtain the pending messages from the queue
>   while(1) {
>     ret= burn_msgs_obtain(...,msg_text,...);
>     if(ret<=0)
>   break;
>     ... interpret msg_text ...
>
>   }

Ah, good to know!

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

I don't like that heuristic :-). I'm sure some people choose to use
different mount points. I'm not sure if I should implement the
automatic unmount at this point, it seems like it is connected to too
many issues. It'd be nice to have, but it's too much trouble right now
for the payoff. Maybe later I'll go and tackle this.

>  > > ... 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
>   should."
>  (Cough, cough)

Maybe this is drive specific? I.e. some drives do cause an error, and
some don't? Hopefully when we release xfburn, the libburn code will
get more exposure, and we can get a better idea about these issues.

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

Yeah, this is an unfortunate situation... as I said, hopefully we'll
get more feedback in the near future.

Thanks again for all the info,
~David


More information about the Libburn-hackers mailing list