Re: Request for cooperation with all burn backends

[scdbackup@gmx.net]

Hi,


Andy Polyakov wrote:
> Have you seen resmgrd?

I found this overview of 2006-09-29:
  http://forgeftp.novell.com//resmgr/web/README.html
which differs a bit from the impression i got from
the SuSE 9.0 man pages. 

One could execute program
  resmgr lock /dev/xyz
and then open the device by normal means, possibly even
with O_EXCL.


Obstacles:

I can see no guarantee that a lock automatically vanishes
when the obtaining process ends, or that a "stale" lock
is recognized with sufficient probability.

Like O_EXCL this seems to lock device file inodes and not
devices. Thus /dev/sr0 and /dev/sg0 might be not coordinated.

The sysadmin has to set up an appropriate resmgrd
configuration before this. 

For us programmers it would be nice to know the resmgr
protocol and thus to get rid of forking an external
program. (A study of resmgr client code should help.)


Conclusion:

For our purposes resmgr is inferior to a working O_EXCL
lock. Except its possible acceptance with auto-mounters.

The current resmgr usage model seems to rather invite
the user to lock the device before growisofs, cdrecord,
wodim or cdrskin get started.

With a shell trap it should be possible to get this
end-user-safe. At least all experiments could be done on
shell wrapper level without changeing the code of the
participiating burn programs.

I now consider to offer this locking on the level of my
backup tool. Maybe it helps against automounters.

But with libburn i am quite unhappy about the outlook
on resmgrd. Neither can i assume to have it set up
properly on the majority of systems, nor does it really
ensure that i do not suffer from outdated locks.

A server with a persistent connection to the client
would be an appropriate implementation of our locking
demands. This server could revoke the lock as soon as
the connection to the client ends.
resmgrd is not designed to fulfill this task, i fear.


Further ideas:

Next i will try to find out wether HAL would be of more
help.

I consider to combine the naming scheme of my own lock
file experiment with a simple server rather than with
persistent files on disk.
The naming scheme hopefully coordinates devices and
not device file inodes. At least with SCSI- and ATAPI-
burners on Linux:

/dev/srN, dev/scdN, /dev/sgN get mapped to
  "scsi_${host}_${channel}_${id}_${lun}"

other device file paths get mapped to
  "rdev_${major}_${minor}
with the device numbers obtained from struct stat.st_rdev .

I believe this scheme is extensible enough for other
operating systems.


Have a nice day :)

Thomas