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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]