From owner-freebsd-fs@FreeBSD.ORG Mon Jun 22 01:17:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BF7C1065675 for ; Mon, 22 Jun 2009 01:17:57 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx1.freebsd.org (Postfix) with ESMTP id DA1E78FC1E for ; Mon, 22 Jun 2009 01:17:56 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from [192.168.1.10] (pool-96-231-140-65.washdc.fios.verizon.net [96.231.140.65]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MIYAN18Jf-000cfM; Sun, 21 Jun 2009 21:17:51 -0400 Message-ID: <4A3EDBB8.6010402@hoyletech.com> Date: Mon, 22 Jun 2009 01:17:44 +0000 From: Nathanael Hoyle User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Snow , Dan Naumov , freebsd-fs@freebsd.org References: <570433.20373.qm@web37308.mail.mud.yahoo.com> <4A3E9D81.1060406@modulus.org> <4A3EB902.8080503@modulus.org> In-Reply-To: <4A3EB902.8080503@modulus.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18LytBHB1A3wkUKo9MCbbRzIt9mSuoI3OMs/OP WnrlfxbOQhyOJHn10i63ZyNluCHj4NRElj1ty9cZ7pKiPGWSXn q3UcoOpeZPZsGSDXb21Jr4q1Ulg/ars Cc: Subject: Re: ufs2 / softupdates / ZFS / disk write cache X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 01:17:57 -0000 Andrew Snow wrote: > Dan Naumov wrote: >>>> Or: >>>> B) use SCSI instead of ATA disks >>>> C) use UFS+gjournal instead of UFS+SU >>>> D) use ZFS instead of UFS+SU >>> All of these solutions still involve disabling of write cache, with >>> a performance hit of varying degrees. (I have tried all of those >>> except gjournal!) > > B) SCSI drives come with write caching disabled by default. But here, > the performance loss is partially made up by Tagged Command Queueing > and faster spindle speeds > > C) gjournal needs to flush the disk cache regularly to maintain > consistence. It doesn't need to do it as often but on a write-heavy > system it isn't ideal for performance because it flushes everything in > the cache and not just the journal. > > D) ZFS - same as (C) > As a minor nitpick to point D, IIRC it is possible to explicitly place the ZIL on a different device than the pool it is for. In this case, if the ZIL is on a dedicated device, then it is possible to flush only the ZIL, rather than all data pending in cache for the zpool. I realize it's a minor distinction / special case, but the option is worth mentioning. -Nathanael