From owner-freebsd-fs@freebsd.org Sat Aug 1 11:36:54 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C27B9B06E2 for ; Sat, 1 Aug 2015 11:36:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18F2F1EB1 for ; Sat, 1 Aug 2015 11:36:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p549CD545.dip0.t-ipconnect.de [84.156.213.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E02E483E402; Sat, 1 Aug 2015 13:36:35 +0200 (CEST) Received: from localhost (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 4C5252B75; Sat, 1 Aug 2015 13:36:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1438428993; bh=GVXm/WSJeT+xWAxY61n9W4o0g5pCucDYuT6YX3cVQ2Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=0/cvWu590QHf/J4EL4IGVxOV6iZIo3L0dihfUcxqjLq1RfKlua2sH4O6XLzgvrkei bJzPd6ZobU6guoluMgPKp/DlzGnHgnFKe13A0bdZDPTyfo1XRex8h5aWomNX43Bz8r /aJD345Udr/Ukdv+KPsj45m+3kELmehHr3F9GR2aecPeZq6mJsEpgIc7mf3A4c1XkM 2FXoWeqyAuDLhDAmgSxlE9+e2hZXuZV6xdD92f7XabyvmCudjGYNwTcSb41qSS2gTM SYgW7dE8SqpRX89MLqE1JfCN+mgBG7/coPDjnPtMMrfKq7nwrxglkNeYmZjNeMQjsR Y/7nZazUpP9Fw== Date: Sat, 1 Aug 2015 13:36:35 +0200 From: Alexander Leidinger To: Quartz Cc: FreeBSD FS Subject: Re: ZFS: Disabling ARC? Message-ID: <20150801133635.00002ecc@Leidinger.net> In-Reply-To: <55BC14B7.9010009@sneakertech.com> References: <55BC14B7.9010009@sneakertech.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E02E483E402.A3B83 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.023, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1439033799.74557@uWyi+f9Z7RPRRqyA/EYoPg X-EBL-Spam-Status: No X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 11:36:54 -0000 On Fri, 31 Jul 2015 20:37:11 -0400 Quartz wrote: > Can someone help clear up a few ZFS basics for me? > > A few recent threads about ARC issues and memory-induced panics have > made me realize I'm not 100% sure I understand ARC as well as I > thought I did. > > Say you have a ZFS file server that houses very large single files > which are very infrequently accessed. For the sake of argument, let's > say you're using ZFS on a home server for your family, and it holds > exclusively a whole bunch of multi-gig bluray rips or whatever > (nothing else). When someone wants to watch something, they copy the > file to their desktop and watch it there. Although the family will > watch several videos each day, any given file will only be accessed > maybe once every couple months. (I know streaming would make more > sense in real life, and that this example is kinda silly in general, > but ignore that for now). No matter if you stream or copy, it's the same operation, read once in a while. > If I understand ARC correctly this would be a worst case scenario, > right? Besides hogging ram, would ARC cause any problems here? Would > disabling ARC and devoting the ram to other things be a wise idea? Is > disabling ARC ever a wise idea? You can tune how the ARC is used: # zfs get all space/export/Movies | grep cache space/export/Movies primarycache metadata local space/export/Movies secondarycache none local "primarycache" is the ARC in RAM, "secondarycache" is a cache device / L2ARC (SSD). "metadata" is directory listing, file sizes, access permissions and the like. So the above example means that metadata is allowed to go to the ARC in RAM, and nothing of the real data in this dataset shall be cached anywhere at all (neither in a cache device nor in RAM). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC