From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 15:26:25 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D65F16A41F for ; Mon, 22 Aug 2005 15:26:25 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B12B343D58 for ; Mon, 22 Aug 2005 15:26:24 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j7MFO301078859; Mon, 22 Aug 2005 17:24:03 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 22 Aug 2005 17:26:17 +0200 To: m.ehinger@ltur.de X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-hackers@FreeBSD.org Subject: Re: IBM Active Protection System Approach X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 15:26:25 -0000 On 22/08/2005, at 10:08, m.ehinger@ltur.de wrote: > what would be the best approach to implement aps on FreeBSD? > > I got an Accelerometer driver which will deliver data. First =20 > Version is available at > https://sourceforge.net/project/showfiles.php?=20 > group_id=3D138242&package_id=3D160977 > > We have to poll the device for information quiet often to detect a =20 > possible shock early enough to park disk drive heads. Urhm, what type of "accidents" is it we want to protect against here ? It will take several tens of mS to get the heads parked if not =20 hundreds, and the worst case scenario would be that the "accident" =20 will happen just as the heads are on the way to the parking zone =20 which would *really* destroy data on there, unless the disk has =20 special HW to just quickly lift the heads or something. > What else must be done to prevent a possible data loss? I think this will need to be tailored to the exact type of "mishap" =20 one wants to protect against. If this is a way to protect against dropping a notebook on the floor =20 then there won't be time for much else than trying to rush the heads =20 to the parking zone. In other setups a flush of buffers (OS level as well as HW level) =20 could be preferred if power loss or HW failure was imminent. - S=F8ren