Re: Request for cooperation with all burn backends
scdbackup@gmx.net wrote:
> this is a request towards all developers of burn backends.
>
> Is it possible we define a common locking mechanism for drives
> which does not depend on hardly documented Linux O_EXCL ?
This way of locking is known not to work.
I believe it has been introduced by Redhat without and discussion
and all Linux vendors who introduce it get into similar problems.
> Something simple and very portable would be needed.
> Advisory locking would be sufficient, i think.
It is unfortunately not for two reasons:
- Linux has a silly problem caused by device aliasing:
You may open the same device under various different
device drivers that avoid knowing from each other in oder
to cause the biggest impact on clean aplications like cdrecord.
- Record Locking only works on files.
> It should cover the problem of one SCSI address having several
> "official" device files. Thus i would propose a lock file which
> contains characteristic unique info about the burner. That would
> also help with device aliases that are no symbolic links.
If Linux would make the internal device instance information available to user
space programs, it would be possible to properly join all device aliases
even on Linux using code inside libscg.
As long as Linux does not offer enough internal information for all
kind of SCSI targets to user space programs (mainly caused by the
unwillingness of Jens Axboe) in order to impact cdrtools, this is
impossible.
> The mechanism on each OS would be allowed to be OS-specific
> since it is supposed to be used only within one system at a time.
> It would not have to be totally safe against race conditions.
> It should suffice to write the own process id into the locking file,
> wait a due time, and check wether the own id survived.
If all applications use the same SCSI transport library and all
OS do not have device aliasing, this is possible.
[Linux specific part removed]
What you mentioned here is highly Linux specific and does nto help
to find a OS independent way.
Unfortunately, it is impossible to have a fact based discussion
with the Linux kernel people on this topic, so starting such a discussion
in the vicinity of Linux does not look like a good idea.
Note that cdrecors currently has no problems on Solaris because it
waits for 10 seconds before it's operation starts. For this reason,
the minimal gracetime in cdrecord is 3 seconds because this is needed
for vold to notice that there is nothing of interest for vold in the
drive (a blank medium).
As Solaris is currently trying to support gnome by modifying vold in a way
that gives better interfaces to gnome and as people on Solaris do care about
cdrecord, let us wait to the end of this year and let us solve the problem
on the future implementations on Solaris first.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
--
To UNSUBSCRIBE, email to cdwrite-REQUEST@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org
Reply to: