From owner-freebsd-current@FreeBSD.ORG Fri Mar 5 16:15:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE42106566C for ; Fri, 5 Mar 2010 16:15:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 219958FC1F for ; Fri, 5 Mar 2010 16:15:35 +0000 (UTC) Received: by fxm23 with SMTP id 23so2772625fxm.3 for ; Fri, 05 Mar 2010 08:15:28 -0800 (PST) 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=Z9tWxazf6i+TepmK85E01ZTW76PhLopGEOjLHfBY59E=; b=FE/qHxSedqDji0ObpThu9dWck1mmCTIV2YO3Q+2AUEhcOpde5KWxS1e09tUUU6EuVM DxtoMrXMrV43meDyuMic/XlooDfMIhxNBInqNNfLHcgX8UqorcT2C4YtXxpgJNRaGkq7 OjcBT9gquxHTcL1d8Fs08/hIQNWn8ukJdAbaY= 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=TiFyWFroA2a8lxtEDNhZbaiLQgFraQVw2unIJg9ZVsfh96Z17MODeDGhzMwzn+x5Gn 0UxwMrHQAAodD1nA2wIAFhZU/zAYvxtppC2jsCW96em263/eXGrIaPsxtXIZUmewjdTH l+dgpFl6+TS/3a/plOVdSVqzXxSm9SIsAkXNQ= Received: by 10.223.100.214 with SMTP id z22mr1073858fan.104.1267805728763; Fri, 05 Mar 2010 08:15:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm1277871fxm.3.2010.03.05.08.15.26 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Mar 2010 08:15:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4B912E1B.1030809@FreeBSD.org> Date: Fri, 05 Mar 2010 18:15:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4B55D9D4.1000008@FreeBSD.org> <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> <4B570B4C.9000203@jrv.org> <4B69817B.8090706@FreeBSD.org> <86hbov3qtg.fsf@ds4.des.no> In-Reply-To: <86hbov3qtg.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD-Current , "James R. Van Artsdalen" Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 16:15:36 -0000 Dag-Erling Smørgrav wrote: > Alexander Motin writes: >> I've just added Power Up In Stand-by (PUIS) feature support into CAM >> ATA in HEAD. It is one of the ways to implement staggered spin-up for >> ATA devices. Now CAM will spin-up no more then 4 of such devices at a >> time. > > Hmm, how does that work? Doesn't the BIOS spin the disks up long before > the kernel even loads? Can you set a flag on the disk to tell it not > to? It depends. I haven't yet seen BIOS (except hardware RAIDs), supporting staggered spin-up. BIOSes I've tested were unaware of PUIS. They were trying to communicate disks in stand-by state, failing and don't even trying to spin them up. In some cases it may be possible to tell BIOS ignore disks on some ports, or completely disable BIOSes on some controllers, to let OS be the first there. On some controllers I've even seen hardware jumpers controlling BIOS operation. Also, as soon as most (all?) BIOSes are unaware of SATA Port Multipliers, disks on ports except first are not probed by BIOS. So disks on first ports could be configured to spun-up as usual, but others may be set to use PUIS. But even if some advanced BIOS will sometimes support PMP and PUIS, OS still should support it also, to be able to handle hot-plug cases. > This is a very real issue for me. I have a file server that can't cold > boot because the disks take too long to spin up and / or the PSU can't > deliver enough power to spin them all up at the same time. I would love > to be able to delay spinning up each disk until it's actually needed > (i.e. /etc/rc.d/zfs start). CAM will spin-up devices with PUIS enabled during initial bus scan. It will do it in stages and system will wait for the completion. Same is for hot-plug. Also, on my tests, PUIS makes hot-plug process less stressful and more controllable. In that case device becomes ready and responsible almost immediately and spin-up process controlled using regular ATA commands. SCSI implements much better spin-up control, but PUIS looks to be the step in right direction, respecting limitations of ATA protocol. -- Alexander Motin