Re: Request for cooperation with all burn backends
Hi,
> > 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.
>
> As for locking, or rather serializing access to [relevant] devices.
> "Very portable" customarily means support for different operating
> systems.
I tested growisofs with an advisory locking system based
on lock file naming conventions, unique owner ids and
synchronization by waiting and verifying survival of owner
ids.
In principle it works - if there weren't all the exit()
in growisofs.c which do not play well with the need to remove
a lock file when work is done.
> Doesn't this kind of doom all "very portable" attempts as
> simply unachievable?
It turned out to be quite obtrusive on growisofs code,
indeed. It gave up that idea for now. Especially since
Joerg seems to be not convinced of it either.
> Secondly. Why do you address back-end developers?
Because i joined that club as junior member by accident.
> Is it really a problem between recording programs?
It is especially a problem between growisofs and libburn
on my 2.4 system.
- growisofs burns of DVD+RW experience data damage in about
25 % of the cases after libburn did a bus scan on the burning drive.
- growisofs burns of DVD-RW stall libburn bus scan as soon as the
active drive is enumerated. Affected growisofs burns have about
50 % probability to be damaged.
> Isn't auto-mounting/-playing facilities
> interfering with ongoing recording *bigger* problem? So if you want to
> make the noble attempt and spend some time convincing developers time is
> better spent talking to that developers. IMHO that is:-)
Well, after i proved my Web 2.0 skills by forging a lock
alliance of cdrtools, dvd+rw-tools, cdrkit and libburn
i will probably approach the auto-community for joining
our convention. :))
> I think that all
> attempts to achieve the goal *purely* in user-land are doomed. 2.6
> O_EXCL on block device appears to be sufficient for intended purpose and
> I personally would rather prefer it back-ported to 2.4 than some
> user-land facility.
O_EXCL locking is promised for 2.4 in the Linux sg HOWTO :
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/open.html
I can offer a patch of 100 to 150 lines in growisofs.c
to achieve locking of /dev/srN or /dev/scdN via the
corresponding /dev/sgM.
Since i implemented that on my system i am free of trouble
between growisofs and libburn.
I published the test version (loudly declaring itself as
inofficial hack) on the libburn-hackers@pykix.org mailing list
in the hope of some test results ... then i wanted to approach
you.
No echo. Everybody is on 2.6 already.
See diff -puN at
http://scdbackup.sourceforge.net/dvd+rw-tools-7.0.tsA60930.diff.txt
The complete package for testing
http://scdbackup.sourceforge.net/dvd+rw-tools-7.0.tsA60930.tar.gz
My own tests on kernel 2.4.21 showed no problems.
> Note that it doesn't have to be /dev/sg. Even though different, both 2.4
> and 2.6 provide interfaces for passing SCSI commands from user-land
> through /dev/cdrom. Well, I have to admit I've never tested
> CDROM_SEND_PACKET interface for non-data recordings... Did libburn
> developers do?
libburn is using /dev/sgN with N out of {0..31} and /dev/hdX with
X out of {'a'..'z'} . Theoretically they could be mixed but in
practice /dev/sgN is for 2.4 with ide-scsi and /dev/hdX is for 2.6.
Both device families are used via the same SG_IO ioctl calls.
I did not thoroughly explore the transport and drive
command level yet. Not to speak of the more artful matters of
disc, session, and track semantics. (Most need for work is
currently in the usability aspects of the library.)
> To summarize. My vote goes for block device addressing,
We both use /dev/hdX on Linux 2.6 and locking seems to work fine.
(Allthough i believe O_EXCL locking should happen earlier
in growisofs.)
> back-porting of O_EXCL to 2.4
Please consider above locking proposal via /dev/sgM.
It should keep away trouble with libburn and hopefully with
cdrecord and wodim. libburn and cdrecord do respect their mutual
locks on kernel 2.4. I tested that several times by accident.
> and convincing auto-mounting/-playing developers to stick
> to it.
For now i would be glad to see Linux 2.4 mutual exclusion working
as it does on my own system now. The eventual abort of growisofs
comes a bit late but elsewise it seems to be ok.
> Note that there
> are left-overs from experiment with resmsg in dvd+rw-tools code [look
> for dev_open], so in case of alternative outcome,
I will have a look at resmgrd (and its relation to HAL
and D-Bus). It could be a model example of a locking service
and one could try to make an implementation on base of it.
Such a proposal could be acceptable to automounters, too.
Have a nice day :)
Thomas
Reply to: