From owner-freebsd-questions@freebsd.org Mon Aug 31 23:14:16 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 AD24A9C6043 for ; Mon, 31 Aug 2015 23:14:16 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DAC4D88 for ; Mon, 31 Aug 2015 23:14:16 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de (port-92-195-125-111.dynamic.qsc.de [92.195.125.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 3BF1C24BD5; Tue, 1 Sep 2015 01:14:12 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id t7VNECph002193; Tue, 1 Sep 2015 01:14:12 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Tue, 1 Sep 2015 01:14:12 +0200 From: Polytropon To: Quartz Cc: freebsd-questions Subject: Re: Stop using a SATA drive Message-Id: <20150901011412.ec085f86.freebsd@edvax.de> In-Reply-To: <55E45757.9000901@sneakertech.com> References: <20150824214252.53aa04c6.freebsd@edvax.de> <55DEF869.1010202@sneakertech.com> <55DEFB5A.3080408@FreeBSD.org> <55DEFC74.3040609@sneakertech.com> <20150828000602.b9a288a8.freebsd@edvax.de> <20150829220809.438bbf30.freebsd@edvax.de> <55E45757.9000901@sneakertech.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Mon, 31 Aug 2015 23:14:16 -0000 On Mon, 31 Aug 2015 09:32:07 -0400, Quartz wrote: > > The remaining question is: Is it technically valid to > > remove a device special file from the devfs file system > > corresponding to a device that currently is not in use > > (anymore), but is _present_ (attached to the system in > > some way)? > > I keep using OSX as a point of reference, but the way they do it is that > once the drive has been "ejected", it's effectively not present anymore. > Their mental model is that a drive can be physically attached without > being 'connected' software-wise, just that the process of establishing > that connection when a device is plugged in has been automated. This leaves the more or less philosophical question: If the user intends to use the disk he just ejected (but which is still connected) again, what does he have to do? Obviously, he cannot mount it anymore - no device file. Does he need to pull the USB cable and so powering down the device, and then plugging it in again, causing a somehow superfluous power cycle, to make the device file re-appear, or is there some "scan for new devices" (equivalent to "camcontrol reset")? > Personally I've never had a problem with this mental model. The problems start when you leave the predefined path. :-) > Many > different things can be physically plugged into a computer without > actually functioning (ie; network cable) so I don't see why drives > should have special rules. This is in fact correct, and again philosophically, think about the importance of the _time_: Just because I plug in something _now_ - it doesn't imply that I intend to interact with it right away, or even worse, in the way the OS believes I will. Example 1: I have a hard disk that is to be subject to a forensic analysis. What I do _not_ want is that it will be automacially mounted r/w, maybe searched for files, or written to. Example 2: I have a DVD which I want to copy some files from. Not now, later. What I do _not_ want is that it starts auto-playing. Example 3: I have a PCCARD wireless network adapter which I need the next day for setting up a WLAN AP "man in the middle" for traffic diagnostics. What I do _not_ want is that it automatically connects to my neighbor's open WLAN right now, and phone home. The "problem" with automatism is that one size doesn't fit everyone. :-) > Any anyway, when I eject a drive it's because > I'm about to physically remove it. In this, and _only_ in this kind of context, it's a fully valid approach. It's just that the question of the technical implementation and its valididy remains, and maybe even that is just a matter of taste. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...