From owner-freebsd-fs@FreeBSD.ORG Thu Jul 21 19:40:59 2011 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 7D794106566B for ; Thu, 21 Jul 2011 19:40:59 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07FAB8FC12 for ; Thu, 21 Jul 2011 19:40:58 +0000 (UTC) Received: by gwb15 with SMTP id 15so1402663gwb.13 for ; Thu, 21 Jul 2011 12:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=NEu1niXbfyQ21WzCI1eEhgJINGl3v9MLnvDWwTjFwaM=; b=pR6kaXHVU9TWymTFJKp95kd35E6SS+NIS+LyumbooOFXGxknFb98C/lbnsts2l2LSI A9Y/a1vwzhgvWhy0r0TOFwhEOb6YZ5uKqp3yiV/4zRPtWWQazfqXwZa99ZGpssu39fvI nxoKMvmi6BZZKMOJKC41ha06WhxHCQQMe8yDM= Received: by 10.100.52.3 with SMTP id z3mr712284anz.127.1311277258245; Thu, 21 Jul 2011 12:40:58 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.198.5 with HTTP; Thu, 21 Jul 2011 12:40:18 -0700 (PDT) In-Reply-To: <4E286F1F.6010502@FreeBSD.org> References: <4E286F1F.6010502@FreeBSD.org> From: Ivan Voras Date: Thu, 21 Jul 2011 21:40:18 +0200 X-Google-Sender-Auth: zcfgMpLQ0P2_CWWFm3SZWRbe2nA Message-ID: To: Martin Matuska Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and large directories - caveat report 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: Thu, 21 Jul 2011 19:40:59 -0000 On 21 July 2011 20:25, Martin Matuska wrote: > Quoting: > ... The default record size ZFS utilizes is 128K, which is good for many > storage servers that will harbor larger files. However, when dealing with > many files that are only a matter of tens of kilobytes, or even bytes, > considerable slowdown will result. ZFS can easily alter the record size of > the data to be written through the use of attributes. These attributes can > be set at any time through the use of the "zfs set" command. To set the > record size attribute perform "zfs set recordsize=32K pool/share". This will > set the recordsize to 32K on share "share" within pool "pool". This type of > functionality can even be implemented on nested shares for even more > flexibility. ... > > Read more: > http://www.articlesbase.com/information-technology-articles/improving-file-system-performance-utilizing-dynamic-record-sizes-in-zfs-4565092.html#ixzz1SlWZ7BM5 Thank you very much - now if only you took as much effort to explain the possible connection between your quote and my post as it took you to find the quote :) As others explained, ZFS definitely does not use fixed block sizes, which I can easily confirm for you by running iostat: www:~> iostat 1 tty ad4 ad6 ad8 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 32 5.87 123 0.70 5.88 122 0.70 5.99 121 0.71 4 0 8 0 88 0 233 1.54 171 0.26 1.54 166 0.25 1.53 172 0.26 10 0 17 1 72 0 78 7.34 181 1.30 7.02 191 1.31 7.46 177 1.29 0 0 8 0 92 0 78 5.50 234 1.25 5.59 232 1.26 5.27 247 1.27 0 0 10 1 89 ^C KB/t varies and is small. Now I'm working under the hypothesis that the directory pseudo-file itself is hugely fragmented and ZFS fragments it even more every time it adds or removes from it. Any ideas how to verify this?