Request for cooperation with all burn backends

[scdbackup@gmx.net]

Hi,

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 ?

Something simple and very portable would be needed. 
Advisory locking would be sufficient, i think.
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.

For SCSI that unique info could be (host,channel,id,lun) as
returned on Linux by ioctl(SCSI_IOCTL_GET_IDLUN), for ATAPI
i would appreciate a similar proposal.

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.


My motivation currently is about growisofs and /dev/srN :

I had the ito open(2) O_EXCL those /dev/srN and /dev/scdM
which have the same SCSI address as the /dev/sgK used by libburn.

But while running on my SuSE 9.0, 2.4.21 kernel :
   growisofs -Z /dev/sr0=/dev/fd/0

i can still sucessfully do in another process
   open("/dev/sr0", O_EXCL|O_NONBLOCK|O_RDWR);

A bold try to run grwoisofs on  -Z /dev/sg0  yielded:
   :-( unable to open("/dev/sg0"): Block device required

With cdrecord the situation is better since we both use /dev/sgN
and thus mutally exclusive locking works for my 2.4.21 system.

I inserted a test print into version 7.0 of growisofs.c

             * For reference, I can't do it earlier as exclusive lock
             * could have been granted to mounted file system, the one
             * we've tried to unmount just a moment ago...
             */

             /* ts A60927 : What devices get locked ? */
             fprintf(stderr,"cdrskin_experimental: ioctl_device= '%s'\n",
                     ioctl_device);

            int fd = open64 (ioctl_device,O_RDONLY|O_NONBLOCK|O_EXCL);
            struct stat64 sb,sc;

and this prints:

   cdrskin_experimental: ioctl_device= '/dev/sr0'

In http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/open.html i read
   "The combination of O_RDONLY and O_EXCL is disallowed."
but that's for /dev/sg* not for /dev/sr* . 
In http://sg.torque.net/scsi/SCSI-2.4-HOWTO/index.html i cannot
find anything about open(2) or O_EXCL.

Is it possible that O_EXCL does not work with sr on 2.4 kernels ?
It works fine with sg on my 2.4.21.

I tried in growisofs.c without success:
   int fd = open (ioctl_device,O_RDWR|O_NONBLOCK|O_EXCL);

Locking worked with hardcoded /dev/sg0 :
   int fd2 = open ("/dev/sg0",O_RDWR|O_NONBLOCK|O_EXCL);

(at the price that cdrskin could not resolve SCSI address "0,0,0"
any more, because /dev/sg0 refused to tell.)

I could provide a translator from /dev/srN to /dev/sgM (which only
works on unlocked devices) but somehow the whole mess makes me think
that a common portable locking mechanism of burn programs would
be the better solution.

I am open to any proposal.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to cdwrite-REQUEST@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org