From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 22 09:19:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45955106566C; Fri, 22 Oct 2010 09:19:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91D338FC1E; Fri, 22 Oct 2010 09:19:00 +0000 (UTC) Received: by bwz3 with SMTP id 3so1034279bwz.13 for ; Fri, 22 Oct 2010 02:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=TRq3Tvh5o85f099oNNthc+hTacuxqgw88WYKNgVn5hw=; b=C0Vj2ghLVmitchc6iX5h14J9FAx+Z9idjVBj6tfyf/9hdu5H5oa1cZa1kXVBgn3C6l v2Y7uZquc0JniMzIw+Xz4Tao2Fq6OcM/cDzKXFv7/USIZ3xejlUYF4ARADCDoaVfhjDB VOL2jzoQwUN9G3kgaN1TRQbj+W5Bt6ENUuj5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BJCi3pbUPluwX91BQoVXUL30mB2LxWRKOB5AtSx1qXa/tjZnXqVOhJR7ArnFgabZgB BaPGtRB++KdVKV5IlfrrmnPWyw9Btmr3EkBXddMNQW8GRncN+LeAgx50cIjWu5Lz9jZ6 4zv3yzGLokkg2xmmexb9bqxGSqHMWCnEowkuU= Received: by 10.204.100.82 with SMTP id x18mr1812905bkn.75.1287739139210; Fri, 22 Oct 2010 02:18:59 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p34sm1969546bkf.3.2010.10.22.02.18.55 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 02:18:57 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC156F5.1050109@FreeBSD.org> Date: Fri, 22 Oct 2010 12:18:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <201009161742.24228.tijl@coosemans.org> <201009161619.o8GGJAmv035378@lurza.secnetix.de> <20101018155944.GA12425@freebsd.org> <868w1r92rf.fsf@ds4.des.no> <20101021122110.GA65490@freebsd.org> In-Reply-To: <20101021122110.GA65490@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , Tijl Coosemans , Oliver Fromme , freebsd-hackers@freebsd.org Subject: Re: Summary: Re: Spin down HDD after disk sync or before power off 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: Fri, 22 Oct 2010 09:19:01 -0000 Alexander Best wrote: > the current implementation (kern.cam.power_down) uses a singe "sleep" > operation, whereas the patch by oliver uses "flush" and "standby immediate". Sleep is just more aggressive. It puts device into deeper sleep state. I don't think it is important from wearing point of view. > unfortunately almost nobody was aware of mav's work at the time of the > discussion. would have been nice to have a note in cam(4) explaining the > purpose of kern.cam.power_down. that way a lot of double work could have been > avoided. That code was expected to handle spindown on shutdown in unified fashion for ATA and SCSI devices without dependency from peripheral driver (even without one), just using different commands for each protocol. It works, but in current implementation it is unreliable. The problem is that it uses polled operation mode, not supported by some controllers or unreliable on some (e.g. atapicam). So the code is disabled now by default. I haven't yet decided it's future: it should be either reworked or reverted. As positive side -- as soon as CAM is not using NewBus at the moment, CAM registers own shutdown handlers. That allows CAM to receive the howto argument, which allows to separate cases of reboot and shutdown cases just by: if ((howto & RB_POWEROFF) == 0) > is the ATA(4) subsystem still being actively worked on or will it die out after > officially switching to ATA_CAM? the question is, if it is worth implementing > hdd spin down for ATA(4)? I don't think it will be really critical. Next months I am going to work on ataraid(4) replacement, which was main declared show stopper for the switch. I hope to trash legacy code some time after switching to ATA_CAM to clear number of odd things (like almost not working port multipliers support or duplicate drivers), required by it. -- Alexander Motin