Stop using a SATA drive

[jd1008]

On 08/27/2015 06:00 PM, Polytropon wrote:
> 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. :-)
>
>
Detach is correct, as that is how it is implemented in Sun OS,
which also has a common heritage with BSD.