Joerg Schilling wrote:
I don't believe Solaris handles locking well if there is a hard link created from a device inode. I saw this when some init script created a hard rather than symbolic link to a device, admiditedly a few years ago.scdbackup@gmx.net wrote:Hi,int grab_sg (int blkfd)Seems to work well for me and my two drives sr0 and sr1. I threw out two of my three functions and made try_to_lock_linux_sg() using grab_sg() instead. The call in builtin_dd() has changed a bit: if (i == 3 && fd >= 0) try_to_lock_linux_sg(ioctl_device, fd);void try_to_lock_linux_sg(char *ioctl_device, int ioctl_dev_fd) { int fd_sg = -1; if ( ( ( strncmp (ioctl_device, "/dev/sr", 7) == 0 && isdigit(ioctl_device[7]) ) || ( strncmp (ioctl_device, "/dev/scd", 8) == 0 && isdigit(ioctl_device[8]) ) ) ) fd_sg = grab_sg(ioctl_dev_fd); if(fd_sg == -2) fprintf (stderr,":-( unable to O_EXCL sg equivalent of %s: " "Other burn program active on drive ?\n", ioctl_device), exit (FATAL_START(errno)); }Forget about this "method". It is known not to work reliably on Linux and similar moethods will not work at all on other OS. The problem on Linux is device aliasing that results in many independent device nodes.
BTW: any attempt to completely lock the device would prevent correct usability even if there war no device aliasing. Cooperative locking is needed in a way that allows and is based not on device nodes but on real hardware targets.Agree. Some form of locking on the actual device is desirable. I'm less sure about cooperative locking, any method which fails if any one program behaves badly is not scalable. Worse yet, bad behaviour by one often shows as a failure in another, increasing time to solution.
A perfect solution also must address locking of partitions vs. locking the entire device. I have a little paper somewhere around on just this issue, and I referenced Plauger's "Law of Least Astonishment" therein. I see the locking issues in Linux as partially political, but there are certainly enouigh technical issues to go around.
-- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979