From owner-freebsd-stable@FreeBSD.ORG Sat Apr 2 17:31:05 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 B0F34106564A for ; Sat, 2 Apr 2011 17:31:05 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from eccles.ee.ryerson.ca (ee.ryerson.ca [141.117.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE1A8FC15 for ; Sat, 2 Apr 2011 17:31:04 +0000 (UTC) Received: from [10.0.1.3] (bas2-toronto09-1176130867.dsl.bell.ca [70.26.85.51]) (authenticated bits=0) by eccles.ee.ryerson.ca (8.14.4/8.14.4) with ESMTP id p32GtCel001946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Apr 2011 12:55:18 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Magda In-Reply-To: <201104020335.p323Zp8Q018666@apollo.backplane.com> Date: Sat, 2 Apr 2011 12:55:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1A4498-0CE0-4CE7-8DD3-6066B85C82AF@ee.ryerson.ca> References: <87d3l6p5xv.fsf@cosmos.claresco.hr> <874o6ip0ak.fsf@cosmos.claresco.hr> <7b15d37d28f8ddac9eb81e4390231c96.HRCIM@webmail.1command.com> <14c23d4bf5b47a7790cff65e70c66151.HRCIM@webmail.1command.com> <201104020335.p323Zp8Q018666@apollo.backplane.com> To: Matthew Dillon X-Mailer: Apple Mail (2.1082) Cc: freebsd-stable@freebsd.org Subject: Re: Constant rebooting after power loss 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: Sat, 02 Apr 2011 17:31:05 -0000 On Apr 1, 2011, at 23:35, Matthew Dillon wrote: > The solution to this first item is for the OS/filesystem to issue a > disk flush command to the drive at appropriate times. If I recall = the > ZFS implementation in FreeBSD *DOES* do this for transaction = groups, > which guarantees that a prior transaction group is fully synced = before > a new ones starts running (HAMMER in DragonFly also does this). > (Just getting an 'ack' from the write transaction over the SATA bus = only > means the data made it to the drive's cache, not that it made it to > the platter). It should also be noted that some drives ignore or lie about these flush = commands: i.e., they say they flushed the buffers but did not in fact do = so. This is sometimes done on cheap SATA drives, but also on expensive = SANS. If the former's case it's often to help with benchmark numbers. In = the latter's case, it's usually okay because the buffers are actually = NVRAM, and so are safe across power cycles. There are also some = USB-to-SATA chipsets that don't handle flush commands and simply ACK = them without passing them to the drive, so yanking a drive can cause = problems. There has been quite a bit of discussion on the zfs-discuss list on this = topic of the years, especially when it comes to (consumer) SSDs.