Re: Request for cooperation with all burn backends
Hi,
Joerg Schilling:
>> Cooperative locking is needed in a way that allows and is based not on
>> device nodes but on real hardware targets.
Bill Davidsen:
> I'm less sure about cooperative locking, any method which fails if any one
> program behaves badly is not scalable.
It seems to be a hard constraint in the burn community
that the locking mechanism has to allow free access to
the drive if the burn program deems its actions harmless.
Full responsibility has as precondition a sufficient
knowledge of the situation, nevertheless. So the burn
programs need at least some means to announce their
disturbance-sensitive activities on a drive and to detect
such announcements before starting any activity which
assumes exclusive usage of the drive.
Bill:
> A perfect solution also must address locking of
> partitions vs. locking the entire device.
Partitions with burner programs ?
How do partitions apply to us ?
> I have a little paper somewhere
If possible i would be interested to read.
As said, i do not strive for a perfect solution
but for one that gives some hope and chance for
mutual good-will programming.
Main concerns currently:
- An unambigous mapping from drive addresses as known
to the burn programs to the physical drives which we
actually want to address.
I consider to put the full load of this to a server
process.
- A minimal footprint in the code of the burn programs
so that everybody is willing to include the necessary
software and to participate in the cooperation.
This client code shall only provide a unique process id,
transfer the known (reversely ambigous) address of the
drive to the server and recieve the reply wether the
(unambigous) drive could be exclusively reserved or not.
> I don't know that any solution which depends on every program
> cooperating will be practical, and in fact automounters seem to ignore
> the rest of the world.
The good willing programs and developers are the
ones whom i want to address here.
If we ever get a practical locking convention implemented
on the most important operating systems then the next step
might be a coordinated move of burn developers towards
automounter developers. It would spare both sides lots of
anger if we would not have our software fighting.
> I'm leaning toward Joerg's thought that locks on inodes referencing
> physical devices should work at the device level to avoid aliasing issues.
This is the other hard constraint that emerged from the
discussion so far: device file locking is insufficient.
Even device driver locking is not what we need.
We need to cooperate on the drive. One drive - one lock.
Not so clear are:
- How much is it worth to us ? How much effort will each
developer accept in order to participate ?
- What operating systems need to be covered by a first
suite of locking servers and how complicated will it
be to implement unique drive identification on each ?
My ideas for Linux are not 100% fool proof but would
work for the configurations known to me:
/dev/hdX device driver or (emulated) SCSI devices.
> SysV message queue
msgget, msgsnd, ...
Indeed a candidate. Installed on my Linux.
Then there is mq_open, mq_send, ...
Labeled "POSIX". Not installed on my Linux.
I will consider to use this.
It has not the advantage of TCP/IP to detect the demise
of a lock holder by the end of the connection.
Have a nice day :)
Thomas
Reply to: