From owner-freebsd-stable@FreeBSD.ORG Tue Aug 30 18:03:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49CE106566B for ; Tue, 30 Aug 2011 18:03:02 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C1D28FC0C for ; Tue, 30 Aug 2011 18:03:02 +0000 (UTC) Received: from webmail.ee.ryerson.ca (eccles [172.16.1.2]) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id p7UHT28R009234; Tue, 30 Aug 2011 13:29:02 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Received: from 206.108.127.2 (SquirrelMail authenticated user dmagda) by webmail.ee.ryerson.ca with HTTP; Tue, 30 Aug 2011 13:29:02 -0400 Message-ID: In-Reply-To: References: <4E5BF15F.9070601@es.net> Date: Tue, 30 Aug 2011 13:29:02 -0400 From: "David Magda" To: "Kevin Oberman" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, dart@es.net Subject: Re: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:03:02 -0000 On Tue, August 30, 2011 11:50, Kevin Oberman wrote: [...] > The more I look at this, the more it seems to me that it is an issue > with the Seagate drive and not a FreeBSD issue. Probably a bug that is > never triggered on Windows, so is largely unnoticed. I suspect Widows > probably orders the command is a subtly different order. [...] Or not the drive per se, but the USB-to-IDE/SATA chipset. A while back on the OpenSolaris zfs-discuss list there was an issue where USB drives would have corrupt ZFS pools if a drive was yanked without a 'zpool export' being run. Even though ZFS is supposed to always be consistent on-disk (because it's transactional), this wasn't happening. It turned that the chipset had a list of particular SATA commands that it allowed through to the drive, and all others were simply answered with "OK", regardless of what actual actions needed to be taken. One of the SATA commands that was NOT whitelisted was the 'cache flush' command--which ZFS needs to make sure that it's data structures were written in the proper order. Turns out the drive and its firmware were fine and doing things properly, it's just that the necessary commands weren't getting to it because of the USB adaptor's chipsset.