From owner-freebsd-fs@FreeBSD.ORG Wed Jan 30 21:56:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6C643145 for ; Wed, 30 Jan 2013 21:56:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id 30961940 for ; Wed, 30 Jan 2013 21:56:10 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so1298286vbb.38 for ; Wed, 30 Jan 2013 13:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wpSwv3N4jMIGGcP8n72/lz2cALhn/QdLAKhy7UP+hEs=; b=mtwbJOBxtUdF6vKUzQssPpCv1g6Z66uP9VaNfEUCyGfzsv4+X6xwWeU+g+NwXi9GCH nhiPiH3r56Iz9kjTx+ZM7dCGMTkHPbEcrXYl1RmoqhW+qI0TbUCMNoOIhYaY4HCagrWW nJonqyNbla7eJkX+qNE7k2BAbzxFEJV6vs2bAIafXk6L5QzWT4xWd8LDhM/73dlRZX8g P7mVU3G4ysL6UzyyB62ewF37cHpVWR9w2ld4hy3seAJmCFIPyCTJ+hdQiT/FOg6zYjIt aXH5ZPqZJUhaxsGHOCphYhdZfsLouNMglO39h/XufIL+eRoXj2rvJqWPRS7/ORSpnx1V +Q2w== MIME-Version: 1.0 X-Received: by 10.220.108.2 with SMTP id d2mr6090053vcp.60.1359582969557; Wed, 30 Jan 2013 13:56:09 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.123.2 with HTTP; Wed, 30 Jan 2013 13:56:09 -0800 (PST) In-Reply-To: References: <19DB8F4A-6788-44F6-9A2C-E01DEA01BED9@dragondata.com> <5267B97C-ED47-4AAB-8415-12D6987E9371@gmail.com> <47975CEB-EA50-4F6C-8C47-6F32312F34C4@dragondata.com> <23E6691A-F30C-4731-9F78-FD8ADDDA09AE@gmail.com> Date: Wed, 30 Jan 2013 13:56:09 -0800 X-Google-Sender-Auth: UFa8nGEIxkYKzwrgcUrOaIq3oic Message-ID: Subject: Re: Improving ZFS performance for large directories From: Artem Belevich To: Kevin Day Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Filesystems 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: Wed, 30 Jan 2013 21:56:10 -0000 On Wed, Jan 30, 2013 at 12:59 PM, Kevin Day wrote: > > Does anyone here understand the significance of "used" being higher than "limit"? Is the limit only a suggestion, or are there cases where there'a certain metadata that must be in arc, and it's particularly large here? arc_meta_limit is a soft limit which basically tells ARC to attempt evicting metadata entries and reuse their buffers as opposed to allocating new memory and growing ARC. According to the comment next to arc_evict() function, it's a best-effort attempt and eviction is not guaranteed. That could potentially allow meta_size to remain above meta_limit. --Artem