https://bugzilla.novell.com/show_bug.cgi?id=208782 ------- Comment #19 from kern@sibbald.com 2006-10-05 05:55 MST ------- I don't seem to be able to access that URL. The response is: "Timeout on server". The rest of this comment you can ignore if you wish .. ======= Since you guys have brought up the problem of no medium present, please permit me to do a bit of general complaining that is not directly related to this bug. Also, I don't imagine you are responsible for my issues with "no medium present" ... Basically, during development of kernel 2.5.x the way the SCSI tape driver responds to an open() call was changed, from not so good to very bad. Prior to the change, the OS would return a file descriptor that could be used, but if there was no medium present would return an error if you attempt to access the medium (certain ioctl()s were permitted). The change made in the 2.5.x kernel causes the SCSI driver to wait approximately 2 minutes if there is no medium in the drive, then to return an error. This is change was a *very* bad idea IMO, even if it does seem to meet some new standard (the people who came up with that obviously never wrote a backup program). This new bad behavior can be avoided by adding O_NONBLOCK to the modes of the open() call, in which case, the kernel will return immediately with a file descriptor (apparently, as in the old way of doing things). The problem is that it is not clear that O_NONBLOCK behaves the same on all OSes, nor is it clear that using O_NONBLOCK does not actually put the fd in non-blocking mode when doing a read() or a write(), which is not generally desired. In the end, my life is vastly complicated, because I am forced to attempt some I/O (rewind) to see if the device has a tape in it or not, and then to close() and reopen the file descriptor without O_NONBLOCK to ensure that on someones system, I don't have a file descriptor in a bizarre state (for a time, I cleared the O_NONBLOCK bit with fnctl(), but this was in the end more complicated). What a programmer really wants is a *universal* way to simply know if there is a tape in the drive or not, then to open() a file descriptor without the OS imposing a wait. In addition to knowing if there is a tape in the drive, programmer wants to know when he/she opens the drive is whether or it is busy (i.e. is it in the process of doing a rewind). ENOMEDIUM is a big help, unfortunately it is Linux specific. The O_NONBLOCK is IMO a kludge (i.e. mistake) that just makes opening a drive much more complicated. If you wonder why a 2 minute wait is bad, then you are probably thinking about a "batch" job trying to do a tar or something. With a modern backup program like Bacula, it is often the user who is via a "console" mounting/unmounting tapes and he gets very impatient and confused if he does some operation and it takes 2 minutes for the program to tell him that there is no medium ... This force me to use the O_NONBLOCK and consequently have a much more complicated program. Sorry to bother you with this, but if you ever happen to run into the SCSI designers, I hope someone can help them understand this problem. ====== -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.