Re: -e option to umount?
[I think this thread belongs only on -current for the moment. Please followup there.] On Thu, Jun 22, 2000 at 01:44:47PM -0700, Brian Fundakowski Feldman wrote: For what it's worth, there's a port, ports/sysutils/eject, which is made to do this. I'm not one to deny a simple feature in the base system, though, even if this feature is not /really/ that simple. There are two problems with ports/sysutils/eject: = It uses only CDIOCEJECT, which will not work for all removable media (e.g. SCSI disks, tapes). = It tries to unmount the device after ejecting it. This doesn't make since for all devices. Even for those that it _does_ make sense, it can be hard to correctly determine how (by what name) the device is mounted. So I wrote a simple utility that ejects media as follows: = Check to see if the given device is known to cam, and if so use camlib to eject it. = If that doesn't work, try the CDIOCEJECT ioctl. = If that didn't work, give up. It is available as a port at: http://www.nectar.com/freebsd/neject.tar Included in the port distfile is a patch (umount.patch) that adds a `-e' option to umount. If you use it, then umount will run eject for each local filesystem that is unmounted. I figure umount should call eject, rather than the other way around, since umount already knows the device name and mount point. I actually think that there should be load/eject media ioctls defined that are not specific to CDs. I'll post a separate message to that effect on -current. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
comments wanted: media load/eject ioctls (was Re: -e option to umount?)
We've had a CDIOCEJECT ioctl `forever'. Several drivers support it, such as cd, acd, and wfd. However, there are other drivers that support removable media but do not support CDIOCEJECT: da and sa. Likewise we have CDIOCCLOSE which should cause a device to load its media. I want to add these ioctls to da and sa [1]. I don't like the CDIO name, though. I'd like to give these ioctls a different name. I'm not sure what header file might be appropriate for them. I'd like to keep the new ioctls binary-compatible with CDIOC(EJECT|CLOSE)-- i.e. use ioctls 24 28. Or maybe I'm the only one who wouldn't like to invoke the name CDIOCEJECT to unload a tape :-) Thanks, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] [1] Are there other drivers which should support media load/eject, that do not already? Do any systems have system-ejectable PC cards for example (never seen such myself)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
Greg Lehey wrote: What do people think about adding a -e option to umount(8) to eject a removable medium where possible? Yes! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Thu, 22 Jun 2000, Wes Peters wrote: Greg Lehey wrote: What do people think about adding a -e option to umount(8) to eject a removable medium where possible? Yes! For what it's worth, there's a port, ports/sysutils/eject, which is made to do this. I'm not one to deny a simple feature in the base system, though, even if this feature is not /really/ that simple. -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I haven't checked), the first I/O after the eject button is pressed will come back with a marker (eg. check condition) with sense information that indicates that a user eject was requested. The page at http://www.microsoft.com/hwdev/respec/storspec.htm says: Storage-Related Specifications from Microsoft The download documents on this page are in Microsoft(R) Word format. After unzipping, these files can be viewed in any text editor, including all versions of Microsoft Word, WordPad, and Microsoft Word Viewer. (This link points to instructions on how to view and print documents in Microsoft Word.) [It's an RTF file, so perhaps the "any text editor" claim could be considered true.] Media Status Notification Support Specification, Version 1.03 (Download: 44K RTF file, published: March 1996; file date = May 20, 1996) Specifies, for ATA and ATAPI devices, the protocol for communicating when the user wants to eject the medium or has inserted a new medium. Published by Microsoft Corporation. Important: For CD-ROM and DVD-ROM drives implementing Media Status Notification, the latest version of packet-based Media Status Notification specification is actually a subsection of the Mt. Fuji specification, which is the command set specification for DVD-ROM that will be released as document SFF 8090. For CD-ROM and DVD-ROM drives, do not use Media Status Notification specification v. 1.03 or earlier, as this version of the specification does not apply to optical storage devices. For complete information, see the current PC System Design Guide. ... Media Status Notification Specification for SCSI and ATAPI Devices, Version 0.1 Specifies, for ATAPI and SCSI devices, the protocol for communicating when the user wants to eject the medium or has inserted a new medium. Published by Microsoft Corporation. DRAFT: Media Status Notification Specification for SCSI and ATAPI Devices, Version 0.1 (Download: 45K RTF file, published: March 1996; file date = May 30, 1996) [The first of the latter two is in HTML; the second of them is in RTF.] The 0.1 specification (the HTML one, at http://www.microsoft.com/hwdev/respec/scsimed.htm ) says A major shortcoming of removable media devices on PC platforms is their inability to report to the host when the user attempts to eject the medium. Currently most removable media devices just eject the medium when the user presses the Eject button, and potentially any data the operating system has not saved to the device is lost. Various volume tracking and locking schemes reduce this risk, but do not eliminate it. Ideally, devices will have a means of communicating to the host that the user wants to eject the medium or has inserted a new medium. This specification defines a protocol for providing this function for SCSI ATA and ATAPI devices. The support is enabled using a new SCSI command, ENABLE MEDIA STATUS, and the media status is retrieved using a new SCSI ATA command, GET MEDIA STATUS. Because it is difficult for a SCSI target to asynchronously interrupt the host due to lack of industry support for Asynchronous Event Notification, the GET MEDIA STATUS command is not completed by the target until a media status change occurs. If tagged command queuing is not supported by the target and/or the host, a means of polling the target for status changes is also specified. Note that in some controllers the unused words in the ID Drive data are returned as 0h. Thus it may be better if the Status Notification support was returned as a 2 bit field, where 00b, 11b are both defined as drive not supporting Status notification. I suspect this is mainly intended for devices such as Zip drives (note the comment about "potentially any data the operating system has not saved to the device is lost"). The 1.03 version mentions only ATA drives, saying A major shortcoming of removable media devices on PC platforms is their inability to report to the host when the user attempts to eject the medium. Currently most removable media devices just eject the medium when the user presses the Eject button, and potentially any data the operating system has not saved to the device is lost. Various volume tracking and locking schemes reduce this risk, but do not eliminate it. Ideally, devices will have a means of
Re: -e option to umount?
Marc van Woerkom [EMAIL PROTECTED] writes: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. # mt -f /dev/rsa0 offline # camcontrol eject cd0 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
At 16:02 -0700 18/6/00, Greg Lehey wrote: What do people think about adding a -e option to umount(8) to eject a removable medium where possible? What's special about mounted devices? I'd prefer to see an eject command which attempts to unmount the device if it's mounted. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On 19-Jun-00 Brandon D. Valentine wrote: On Mon, 19 Jun 2000, Bob Bishop wrote: ejected. I know nothing about what happens when I hit the eject button on a CDROM drive. Anyone care to speculate on if that's a reasonable thing to implement? I think this sort of stuff should be handled by an event daemon.. It could handle stuff like a user hitting the eject button, someone pressing a magic key on the keyboard, and apm events etc.. then do something about it. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Mon, Jun 19, 2000 at 02:53:45 -0400, Brandon D. Valentine wrote: On Mon, 19 Jun 2000, Bob Bishop wrote: What's special about mounted devices? I'd prefer to see an eject command which attempts to unmount the device if it's mounted. What'd be really spiffy is if when I hit the eject button on my CDROM drive that whatever scsi signal that event generates, was intercepted by the kernel and, provided the filesystem met the normal criteria for being umount'd(i.e. nothing accessing it), it would be umount'd and then ejected. I know nothing about what happens when I hit the eject button on a CDROM drive. Anyone care to speculate on if that's a reasonable thing to implement? That's a cool idea, but unfortunately, it won't work with any hardware I know of. In order for that to work, the CDROM drive would have to generate an AEN (Asynchronous Event Notification) and send it to the controller, which would have to be capable of functioning as a target as well as an initiator. Then the controller would have to pass that back up to some process that would then unmount the drive, which would also give the cd(4) driver its final close and allow removal of the media. Then the eject could proceed. The problem is that I haven't yet seen a SCSI device (well, short of a FreeBSD box) that is capable of doing AENs, since most SCSI devices can't be both target and initiator. They're generally just targets. Likewise, most controllers only function as initiators. The Adaptec and Qlogic controllers are exceptions in FreeBSD. The Symbios/LSI controllers could probably do target mode as well, given the right firmware and driver support. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
That's a cool idea, but unfortunately, it won't work with any hardware I know of. In order for that to work, the CDROM drive would have to generate an AEN (Asynchronous Event Notification) and send it to the controller, which would have to be capable of functioning as a target as well as an initiator. Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I haven't checked), the first I/O after the eject button is pressed will come back with a marker (eg. check condition) with sense information that indicates that a user eject was requested. Then the controller would have to pass that back up to some process that would then unmount the drive, which would also give the cd(4) driver its final close and allow removal of the media. That's pretty much a given part of the media daemon implementation, and really not all that hard. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Mon, Jun 19, 2000 at 00:27:35 -0700, Mike Smith wrote: That's a cool idea, but unfortunately, it won't work with any hardware I know of. In order for that to work, the CDROM drive would have to generate an AEN (Asynchronous Event Notification) and send it to the controller, which would have to be capable of functioning as a target as well as an initiator. Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I haven't checked), the first I/O after the eject button is pressed will come back with a marker (eg. check condition) with sense information that indicates that a user eject was requested. Some may, but the Panasonic DVD drive I just tried here didn't pass back any sort of error in response to the TUR I sent it after pressing the eject button. In any case, if an error were returned, the only way you could get that to work would be to have the media daemon continually ping the drive with the mounted media, and then unmount it in response to the (likely) unit attention condition. Then the controller would have to pass that back up to some process that would then unmount the drive, which would also give the cd(4) driver its final close and allow removal of the media. That's pretty much a given part of the media daemon implementation, and really not all that hard. True enough. It's getting a drive that supports AEN that is hard. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
It seems Mike Smith wrote: That's a cool idea, but unfortunately, it won't work with any hardware I know of. In order for that to work, the CDROM drive would have to generate an AEN (Asynchronous Event Notification) and send it to the controller, which would have to be capable of functioning as a target as well as an initiator. Hmm. If SCSI drives are anything like ATAPI drives (and here I confess I haven't checked), the first I/O after the eject button is pressed will come back with a marker (eg. check condition) with sense information that indicates that a user eject was requested. This is not true for the wast majority of ATAPI devices, they plain ignore the eject button if the media is locked. The only drive I've seen this working on is the Onstream ADR tape, which has a whole palette of other problems :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
[trimmed cc: list, now including only -current] On Sun, Jun 18, 2000 at 11:54:51PM -0400, Francisco Reyes wrote: Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. And you'd find it, at least for SCSI devices, in camcontrol(8). e.g. % camcontrol eject cd0 This works for SCSI tapes as well. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On 19-Jun-00 Jacques A . Vidrine wrote: [trimmed cc: list, now including only -current] On Sun, Jun 18, 2000 at 11:54:51PM -0400, Francisco Reyes wrote: Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. And you'd find it, at least for SCSI devices, in camcontrol(8). e.g. % camcontrol eject cd0 This works for SCSI tapes as well. /usr/sbin/cdcontrol -f /dev/acd0c eject works for ATAPI CDs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Mon, 19 Jun 2000 01:28:27 MDT, "Kenneth D. Merry" wrote: In any case, if an error were returned, the only way you could get that to work would be to have the media daemon continually ping the drive with the mounted media, and then unmount it in response to the (likely) unit attention condition. This is how the MacOS does it, at least prior to MacOS X. If the CD-ROM is external and powered-down after the MacOS boots, the Mac then hangs periodically trying to ping it. Really screws up performance. :) -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-e option to umount?
What do people think about adding a -e option to umount(8) to eject a removable medium where possible? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
What do people think about adding a -e option to umount(8) to eject a removable medium where possible? SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Here are the manpages for comparison: Irix 6.5: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650db=manfname=/usr/share/catman/u_man/cat1/eject.zsrch=eject Solaris 2.7: http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=SunOS+5.7format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=OpenBSD+2.6format=html http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=NetBSD+1.4format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
/usr/ports/sysutils/eject On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. OpenBSD 2.6 uses 'mt' and 'eject' NetBSD 1.4 uses 'eject' as well. http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=OpenBSD+2.6format=html http://www.FreeBSD.org/cgi/man.cgi?query=ejectapropos=0sektion=0manpath=NetBSD+1.4format=html Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
On Sun, 18 Jun 2000 21:06:52 +, Charles Anderson wrote: /usr/ports/sysutils/eject On Mon, Jun 19, 2000 at 02:09:44AM +0200, Marc van Woerkom wrote: SGIs and SUNs use an 'eject' command for CDs and DAT tapes. Whether as a separate command or as part of umount this is certainly something worth having by default. In particular new users may be a while before they find ports/packages or will just end up in the questions list. Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. Francisco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
Francisco Reyes wrote: Whether as a separate command or as part of umount this is certainly something worth having by default. In particular new users may be a while before they find ports/packages or will just end up in the questions list. Well, you could have both. For example, you could have the -e switch to umount which performs the eject function. In addition, you could have "eject" as a link to umount, and umount itself would check argv[0] to see if it is being executed as eject or umount. If it's eject instead of umount, then perform whatever action the -e flag does. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
