How to coordinate a DVD burn program with udev ?

How to coordinate a DVD burn program with udev ?

[Thomas Schmitt]

Hi,

i am developer of libburn and CD/DVD/BD burn program xorriso.
It seems urgent that i coordinate the activities of libburn with the
activities of udev.

What is the recommended way for a library resp. a console program
to tell udev, that the drive and the media will undergo arbitrary
changes and should not be accessed during that time ?


The particular problem case:

On an installation of Debian GNU/Linux 6.0.2 amd64, /dev/dvdrw vanishes
if libburn loads the tray. It comes back only if some other program run
uses the /dev/sr device file to which the link should point.

The effect is not always reproducible. Typically it happens with DVD+RW
media, not with CD-RW or empty tray. It seems related to the habit
of xorriso to inspect the media for existing ISO 9660 filesystems.
If the system is in the mood for it, then it already happens with
  xorriso -outdev /dev/sr0 
Less frequently i can reproduce it with wodim
  wodim dev=/dev/sr0 -toc
Quite reliably it happens with a xorriso burn run on DVD+RW (e.g. /usr/bin
to DVD+RW):
  xorriso -outdev /dev/sr0 -blank as_needed -add /usr/bin --


There are two drives attached to the system:
  a SATA DVD burner  SH-S223B
  a PATA DVD-ROM     SH-D162C
Mostly the burner is sr0, but on some days it is sr1. So udev's links
are needed to configure persistent addresses in backup programs.

-----------------------------------------------------------------------------
/etc/udev/rules.d/70-persistent-cd.rules
-----------------------------------------------------------------------------
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.

# CDDVDW_SH-S223B (pci-0000:00:11.0-scsi-2:0:0:0)
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

# DVD-ROM_SH-D162C (pci-0000:00:14.1-scsi-0:0:0:0)
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM="block", ENV{ID_CDROM}="?*", ENV{ID_PATH}="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
-----------------------------------------------------------------------------

After booting, i executed
  udevadm control --log-priorityfibug

Then i put a DVD+RW into the tray, leave it open and execute:
  xorriso -outdev /dev/sr0

xorriso loads the tray by SCSI command START/STOP UNIT. A few seconds
later /dev/dvdrw is gone.
The vanishing link is accompanied by these messages in /var/log/daemon.log :
------------------------------------------------------------------

Sep  9 22:00:41 debian2 udevd[435]: seq 1274 queued, 'change' 'scsi'
[...]
Sep  9 22:00:41 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep  9 22:00:41 debian2 cdrom_id[21698]: custom logging function 0x7f17909c9010 registered
Sep  9 22:00:47 debian2 cdrom_id[21698]: unable to open '/dev/sr0'
Sep  9 22:00:47 debian2 udevd-work[21697]: '/lib/udev/cdrom_id' (stderr) 'unable to open '/dev/sr0''
Sep  9 22:00:47 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' returned with exitcode 1
[...]
Sep  9 22:00:48 debian2 udevd-work[21697]: update old name, '/dev/dvdrw' no longer belonging to '/devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0'
Sep  9 22:00:48 debian2 udevd-work[21697]: no reference left, remove '/dev/dvdrw'
[... no attempt to create a new /dev/dvdrw ...]
Sep  9 22:00:48 debian2 udevd[435]: seq 1275 done with 0

------------------------------------------------------------------

It looks as if xorriso's activities block the drive while udev is trying
to get access to it in the time between 22:00:41 and 22:00:47.

The subsequent repair happens by accessing the drive again with another 
  xorriso -outdev /dev/sr0
This time the tray is closed.

------------------------------------------------------------------

Sep  9 22:01:06 debian2 udevd[435]: seq 1276 queued, 'change' 'scsi'
[...]
Sep  9 22:01:06 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep  9 22:01:06 debian2 cdrom_id[22669]: custom logging function 0x7f3e72142010 registered
Sep  9 22:01:10 debian2 cdrom_id[22669]: probing: '/dev/sr0'
Sep  9 22:01:10 debian2 cdrom_id[22669]: INQUIRY: [TSSTcorp][CDDVDW SH-S223B ][SB02]
[... many other SCSI inquiry command results ...]
Sep  9 22:01:16 debian2 udevd-work[21697]: LINK 'dvdrw' /etc/udev/rules.d/70-persistent-cd.rules:11
[...]
Sep  9 22:01:16 debian2 udevd-work[21697]: creating link '/dev/dvdrw' to '/dev/sr0'
Sep  9 22:01:16 debian2 udevd-work[21697]: creating symlink '/dev/dvdrw' to 'sr0'
[...]
Sep  9 22:01:16 debian2 udevd[435]: seq 1277 done with 0

------------------------------------------------------------------

wodim seems a bit less problematic, because it does not perform READ
commands. xorriso does this to learn about possible ISO 9660 fileystems.
I assume they add a few extra seconds to the drive occupation.


I tried to load the tray by
  ioctl(fd, CDROMCLOSETRAY, 0);
before performing SCSI command START/STOP UNIT. No improvement seen.


Have a nice day :)

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to coordinate a DVD burn program with udev ?

[Tom Gundersen]

On Sat, Sep 10, 2011 at 12:34 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> i am developer of libburn and CD/DVD/BD burn program xorriso.
> It seems urgent that i coordinate the activities of libburn with the
> activities of udev.
>
> What is the recommended way for a library resp. a console program
> to tell udev, that the drive and the media will undergo arbitrary
> changes and should not be accessed during that time ?
>
> The particular problem case:
>
> On an installation of Debian GNU/Linux 6.0.2 amd64, /dev/dvdrw vanishes
> if libburn loads the tray. It comes back only if some other program run
> uses the /dev/sr device file to which the link should point.
>
> The effect is not always reproducible. Typically it happens with DVD+RW
> media, not with CD-RW or empty tray. It seems related to the habit
> of xorriso to inspect the media for existing ISO 9660 filesystems.
> If the system is in the mood for it, then it already happens with
>  xorriso -outdev /dev/sr0
> Less frequently i can reproduce it with wodim
>  wodim dev=/dev/sr0 -toc
> Quite reliably it happens with a xorriso burn run on DVD+RW (e.g. /usr/bin
> to DVD+RW):
>  xorriso -outdev /dev/sr0 -blank as_needed -add /usr/bin --
>
>
> There are two drives attached to the system:
>  a SATA DVD burner  SH-S223B
>  a PATA DVD-ROM     SH-D162C
> Mostly the burner is sr0, but on some days it is sr1. So udev's links
> are needed to configure persistent addresses in backup programs.

Could you possibly use one of the /dev/disk/by-* links instead? As far
as I understand, the rule generator is being deprecated.

Sorry to not answer your main question, I'm not sure exactly what is
happening... Maybe someone else can shed some light on it?

Cheers,

Tom

Re: How to coordinate a DVD burn program with udev ?

[Thomas Schmitt]

Hi,

Tom Gundersen wrote:
> Could you possibly use one of the /dev/disk/by-* links instead? As far
> as I understand, the rule generator is being deprecated.

Aside from the general problem, i can of course advise my users to use
whatever is reliably existent and can be unambigously documented.
The files in /dev/disk/by-id seem not to represent any of the two DVD drives.
In /dev/disk/by-path i see them as
  /dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0
  /dev/disk/by-path/pci-0000:00:14.1-scsi-0:0:0:0
But i understand that these addresses are prone to change at boot time, too.
And they would uglify any program message that contains a drive address.

Alternatively one can find the desired /dev/sr address by running
  xorriso -devices
I could even implement in libburn a functionality similar to udev
which identifies drives by unique persistent properties.

But that would not prevent other problems which can arise from
udev trying to inspect the busy CD drive.


> Sorry to not answer your main question, I'm not sure exactly what is
> happening... Maybe someone else can shed some light on it?

The vanishing links are only one example symptom of the general problem
that udev tries to perform SCSI commands on a CD drive that is already
aquired with open(O_EXCL) and might be brought into a state which does
not tolerate such interference.
Especially with media types CD-R, CD-RW and DVD-R this often results in
misburns.

Obviously there are race conditions deciding over success or failure
of the coexistence of udev and burn program. 
xorriso is hit more than the others, because it inspects the media
content additionally to the drive's MMC properties.
Nevertheless i can reproduce the problem with wodim.
It is a general one.


libburn and xorriso are part of a project that tries to improve the
neighborhood relations between Linux and burn programs.
Different to growisofs and wodim it is under maintenance (by me),
and different to the author of cdrecord i am willing to follow
instructions from the Linux developers.

But first i need to get such instructions when Linux changes its behavior.
The random permutation of /dev/sr addresses at boot time is such a change.
I understand the recommended way to cope with this device juggling
is to use the udev links.
Now what shall a user think of udev and/or xorriso if this recommended
solution goes up in smoke on first use ?


Is there a better place than this mailing list where i could ask for advise ?

Especially i wonder what the designers of kernel and udev have planned
for the use case of CD/DVD/BD burning.


Have a nice day :)

Thomas

Re: How to coordinate a DVD burn program with udev ?

[Tom Gundersen]

On Mon, Sep 12, 2011 at 11:12 AM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> Tom Gundersen wrote:
>> Could you possibly use one of the /dev/disk/by-* links instead? As far
>> as I understand, the rule generator is being deprecated.
>
> Aside from the general problem, i can of course advise my users to use
> whatever is reliably existent and can be unambigously documented.
> The files in /dev/disk/by-id seem not to represent any of the two DVD drives.

Oh, that's odd. I have "by-id/ata-HL-DT-ST_DVDRAM_GSA-H66N_K6578SE0620
-> ../../sr0" on my system. Don't know why that would not exist.

> In /dev/disk/by-path i see them as
>  /dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0
>  /dev/disk/by-path/pci-0000:00:14.1-scsi-0:0:0:0
> But i understand that these addresses are prone to change at boot time, too.

The rules you posted in your first mail create the symlinks based on
these paths, so they should be exactly as reliable as your symlinks.

> And they would uglify any program message that contains a drive address.

Even if you use these things internally, you could use something else
for display. Have a look at "% udevadm info --query=all -n
/dev/disk/by-path/pci-0000:00:11.0-scsi-2:0:0:0" to see the available
information you could get from udev.

> Alternatively one can find the desired /dev/sr address by running
>  xorriso -devices
> I could even implement in libburn a functionality similar to udev
> which identifies drives by unique persistent properties.
>
> But that would not prevent other problems which can arise from
> udev trying to inspect the busy CD drive.

I guess this is a bug in the rule generators, that should be fixed
there. I think several distro's have stopped shipping these things
though, so there might not be much interest in working on them. That
said, to the best of my knowledge Debian are still supporting them, so
there is still hope :-)

> Is there a better place than this mailing list where i could ask for advise ?

You could try on irc in #udev, or you could file a bug report with
your distro (there is no udev bugtracker).

-t

Re: How to coordinate a DVD burn program with udev ?

[Thomas Schmitt]

Hi,

me:
> > Is there a better place than this mailing list where i could ask for
> > advise ?

Tom Gundersen wrote:
> you could file a bug report with your distro

Anybody here who knows where to get the attention of the Debian people
who would be in charge ?

(I already have a Debian bug open for problems with U3 memory sticks
 which confuse the system by pretending to be a USB hub with CD-ROM and
 memory stick. Might well be udev related. No reply. Possibly filed
 towards the wrong package.)


Have a nice day :)

Thomas

Re: How to coordinate a DVD burn program with udev ?

[Thomas Schmitt]

Hi,

> I believe Marco d'Itry is your guy.
> [...]
> Good luck,

Thanks a lot for your advise.


Have a nice day :)

Thomas