Date: Fri, 28 Aug 2015 02:00:29 +0200 From: Polytropon <freebsd@edvax.de> To: Quartz <quartz@sneakertech.com> Cc: freebsd-questions@freebsd.org Subject: Re: Stop using a SATA drive Message-ID: <20150828020029.c3c53813.freebsd@edvax.de> In-Reply-To: <55DFA213.4030304@sneakertech.com> References: <CAPi0psvT5aaHR7kU%2B28qwVDdutyMn7LjhFUGZRWctz4gGfgvgw@mail.gmail.com> <20150824214252.53aa04c6.freebsd@edvax.de> <55DEF869.1010202@sneakertech.com> <20150828000118.31f33a35.freebsd@edvax.de> <55DFA213.4030304@sneakertech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Aug 2015 19:49:39 -0400, Quartz wrote: > > > That would surely be possible if the device in question > > would implement a proper reaction to the "eject" command. > > If it does, and how it does it, is up to the manufacturer. > > Let's say you send the "eject" command to the drive - the > > firmware then says goodbye to the host - the device file > > disappears. > > ---- > > > Yes - mostly the software inside the device, which we > > commonly call firmware. On USB, and to a certain extent, > > on SATA, the device identifies to the system and enters > > a communication with it: stating what device class, who > > built it, which model, what capabilities are available > > and so on. If the firmware is able to delete that > > connection (which is, after all, a _data_ exchange, > > not primarily an electric connection), the OS would > > act accordingly by removing the device file entry. > > > > This line of reasoning doesn't make any sense, or at least it's not > related to what I was talking about. Let me try phrasing it a different > way: 'diskutil eject foo' will kick the disk off an OSX system and > remove its entry from /dev, and this functionality works across all > devices and adapters regardless of make or model. Whatever the 'eject' > command is doing, it's clearly entirely software side within the OS*. > Being software, FreeBSD should be capable of the same, especially > considering both OSs have such a close common heritage. I understand. This can be the OS-side of software which causes the removal of the device entry as a "side effect". While the disk device itself doesn't know how to eject itself, the diskutil program deregisters the device entry and removes the device from the current bus content list. Maybe there's even a "re-attach" command available to make the device file reappear (for example by scanning the bus again). This is possible. However, in regards of disk drives, I wouldn't call this procedure "eject", but maybe better "detach". In retrospect, ye olde "atacontrol" _had_ this functionality. See the dusty historic manual for details. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150828020029.c3c53813.freebsd>