From owner-freebsd-fs@FreeBSD.ORG Thu Mar 27 14:33:27 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8886E953 for ; Thu, 27 Mar 2014 14:33:27 +0000 (UTC) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43B3E8FC for ; Thu, 27 Mar 2014 14:33:26 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id s2REQKpk023082; Thu, 27 Mar 2014 09:26:20 -0500 (CDT) Date: Thu, 27 Mar 2014 09:26:20 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Joar Jegleim Subject: Re: zfs l2arc warmup In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Thu, 27 Mar 2014 09:26:20 -0500 (CDT) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:33:27 -0000 On Thu, 27 Mar 2014, Joar Jegleim wrote: > Is this how 'you' do it to warmup the l2arc, or am I missing something ? > > The thing is with this particular pool is that it serves somewhere > between 20 -> 30 million jpegs for a website. The front page of the > site will for every reload present a mosaic of about 36 jpegs, and the > jpegs are completely randomly fetched from the pool. > I don't know what jpegs will be fetched at any given time, so I'm > installing about 2TB of l2arc ( the pool is about 1.6TB today) and I > want the whole pool to be available from the l2arc . Your usage pattern is the opposite of what the ARC is supposed to do. The ARC is supposed to keep most-often accessed data in memory (or retired to L2ARC) based on access patterns. It does not seem necessary for your mosaic to be truely random across 20 -> 30 million jpegs. Random across 1000 jpegs which are circulated in time would produce a similar effect. The application building your web page mosiac can manage which files will be included in the mosaic and achieve the same effect as a huge cache by always building the mosiac from a known subset of files. The 1000 jpegs used for the mosaics can be cycled over time from a random selection, with old ones being removed. This approach assures that in-memory caching is effective since the same files will be requested many times by many clients. Changing the problem from an OS-oriented one to an application-oriented one (better algorithm) gives you more control and better efficiency. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/