From owner-freebsd-fs@FreeBSD.ORG Fri Nov 16 03:55:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50A17984 for ; Fri, 16 Nov 2012 03:55:20 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id B82E68FC08 for ; Fri, 16 Nov 2012 03:55:19 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2311747lbb.13 for ; Thu, 15 Nov 2012 19:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=VZ7URePKaagqoqxuxljiu5Ng1Ev7Pc+j9A2JA3ybST8=; b=FzoohHvDjS4+dEECF2e040E6nOn6mlPCZ5SQqE/Mri04W08MT85gy0Hr9E+R+2TmcK AIIRasP/1sqfl11wUvAp0+CPFHto3v0elOepkFQmWrf8yVHngBDqN0N6K0+ZLdmh9Gai YFN8Bst1DbzA55ex/ORONX9TXFpU2Cjnwd6Xw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=VZ7URePKaagqoqxuxljiu5Ng1Ev7Pc+j9A2JA3ybST8=; b=MvNmbMrEvboQKxti3PseviZAP7v6vL4MMRSNlksYNy65y4djgfB9DV1Vo3Rqn2wtUQ /aXGjXO5ywlHEeYZ/vwJJxj6PP4pka0sVvvKmaN4v6IAQZ6biM9Zw29TbMS5oP2ulRGj fc4YqIyUMRkNNvylleIVNrQkemdikxUvEoIkoRwt27feF8GevTVkXy/ldSgNHSf2inNg 0wkE4ReXDyPSXQe3HTfTGIvbNbMyKIr3anukJ2LrNwTYIUuE80K5YZm1wTPzV05LnMa/ kksEwEoGdHwNUZu1NxeOXeQDqlu1mUq20OF/CcGwGi9AJ7eMoITHUAH2bAzGeXsNHiG+ vKTw== Received: by 10.112.54.40 with SMTP id g8mr1479635lbp.49.1353038118300; Thu, 15 Nov 2012 19:55:18 -0800 (PST) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.112.25.166 with HTTP; Thu, 15 Nov 2012 19:54:46 -0800 (PST) In-Reply-To: <50A31D48.3000700@shatow.net> References: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> <50A31D48.3000700@shatow.net> From: Eitan Adler Date: Thu, 15 Nov 2012 22:54:46 -0500 X-Google-Sender-Auth: ftb5aLdlPWd8z8-nB2LfQHb15dM Message-ID: Subject: Re: SSD recommendations for ZFS cache/log To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlc7hCJOoG8aBIWlgHqb9V4Xor9lcpLCD0/KbJQWoqQcebooPcuxfha40IYmor4UFTgb9Kn Cc: FreeBSD FS , Stephen McKay X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 03:55:20 -0000 On 13 November 2012 23:25, Bryan Drewery wrote: > IMHO this whole post should be enshrined into an FAQ or manpage or wiki. > It's very informative and compelling. Sounds good. Can people here please tell me what is wrong in the following content? Is there additional data or questions to add? Please note that I've never used ZFS so being whacked by a cluebat would be helpful. commit 1675274e40464fb37f822a176b9eed28ea729947 Author: Eitan Adler Date: Thu Nov 15 22:52:33 2012 -0500 Add a section in the FAQ about ZFS Reviewed by: ??? Approved by: ??? diff --git a/en_US.ISO8859-1/books/faq/book.xml b/en_US.ISO8859-1/books/faq/book.xml index 7ad4974..caffad1 100644 --- a/en_US.ISO8859-1/books/faq/book.xml +++ b/en_US.ISO8859-1/books/faq/book.xml @@ -5367,6 +5367,62 @@ C:\="DOS" + + + ZFS + + + + + What is the ZIL and when does it get used? + + + + The ZIL (ZFS + intent log) is a write cache for ZFS. All writes get + recorded in the ZIL. Eventually ZFS will perform a + Transaction Group Commit in which it + flushes out the data in the ZIL to disk. + + + + + + What is the L2ARC? + + + + The L2ARC is a read cache stored + on a fast device such as an SSD. It is + used to speed up operations such as deduplication or + encryption. This cache is not persisent across + reboots. Note that RAM is used as the first layer + of cache and the L2ARC is only needed if there is + insufficient RAM. + + + + + + Is enabling deduplication advisable? + + + + The answer very much depends on the expected workload. + Deduplication takes up a signifigent amount of RAM and CPU + time and may slow down read and write disk access times. + Unless one is storing data that is very heavily + duplicated (such as virtual machine images, or user + backups) it is likely that deduplication will do more harm + than good. Another consideration is the inability to + revert deduplication status. If deduplication is enabled, + data written, and then dedup is disabled, those blocks + which were deduplicated will not be duplicated until + they are next modified. + + + + -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams