From owner-freebsd-questions@freebsd.org Fri Aug 28 00:05:43 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F04CB9C460C for ; Fri, 28 Aug 2015 00:05:42 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B97E414CE for ; Fri, 28 Aug 2015 00:05:42 +0000 (UTC) (envelope-from jd1008@gmail.com) Received: by iods203 with SMTP id s203so76081100iod.0 for ; Thu, 27 Aug 2015 17:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=CD4883rDT2w41T6bpgFHoDoWBjP+TdZAbET2Vg/0lsc=; b=mqWLBe4MVCZmmVvbOHSr546yTqtW4mZ7GONIyEiXMLsmPKTXEMojSOg8f/VzFE/Gsh 8SQPGD9MkuVEVGWfeyYu37l/0QRl3zi2xK4f4Icu/yw4tJ47Ja3IqawvTPAuWH3tmP+U taPegcLZYwmlRutgMwdUNwTPM5Wd7OowYDuhSUQnDOVBneBN41Hbw25njDHy48x7liUS H7ADThTO7R4grXbs9UWKqeAp6fvL2TU6A7IlYAOfGxeOUZjnMIPFpgv712U3v9M9dRx8 Hhp/ekhws/itzPm8ES54ba2dEUgYmiiccn77tJxMm7SjMeyqehjfxzhFVNpvi3H3967D GKXQ== X-Received: by 10.107.168.25 with SMTP id r25mr12272245ioe.32.1440720342165; Thu, 27 Aug 2015 17:05:42 -0700 (PDT) Received: from localhost.localdomain ([50.243.6.59]) by smtp.googlemail.com with ESMTPSA id a8sm621043igo.2.2015.08.27.17.05.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 17:05:41 -0700 (PDT) Subject: Re: Stop using a SATA drive To: freebsd-questions@freebsd.org References: <20150824214252.53aa04c6.freebsd@edvax.de> <55DEF869.1010202@sneakertech.com> <20150828000118.31f33a35.freebsd@edvax.de> <55DFA213.4030304@sneakertech.com> <20150828020029.c3c53813.freebsd@edvax.de> From: jd1008 Message-ID: <55DFA60E.5020209@gmail.com> Date: Thu, 27 Aug 2015 18:06:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150828020029.c3c53813.freebsd@edvax.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 00:05:43 -0000 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.