Date: Thu, 21 Jul 2011 22:56:36 +0200 From: Martin Matuska <mm@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and large directories - caveat report Message-ID: <4E289284.5020800@FreeBSD.org> In-Reply-To: <CAF-QHFX_KmPQjX0AahwE-RTFt-TznRhKzah_eK6tce3dnhomZg@mail.gmail.com> References: <j09hk8$svj$1@dough.gmane.org> <4E286F1F.6010502@FreeBSD.org> <CAF-QHFX_KmPQjX0AahwE-RTFt-TznRhKzah_eK6tce3dnhomZg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21. 7. 2011 21:40, Ivan Voras wrote: > 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 I agree to that. I tried some more digging and stomped on this opensolaris mailing list thread: It starts here: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg35150.html With an interesting user report here (nice summary): http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg35189.html Most times they blame the way the client utilities work with directories (sorting etc.). Now to some more relevant options: It is also possible to do metadata-only caching for a dataset: zfs set primarycache=metadata L2 can be modified as well: zfs set secondarycache=metadata If I find some time I can run some simulations on this to see how it performs compared to primarycache=all. The vdev read-ahead cache might also have a negative impact here (lots of wasted IOPS), mostly if the blocks are spread around the vdev. We have followed what Illumos did and vdev cache is now disabled by default. I have updated the zfs-stats tool (ports: sysutils/zfs-stats) with latest Jason J. Hellenthal's arc_summary.pl, it gives a good overview of ZFS sysctl's: https://github.com/mmatuska/zfs-stats -- Martin Matuska FreeBSD committer http://blog.vx.sk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E289284.5020800>