From owner-freebsd-fs@freebsd.org Sat Aug 29 19:21:11 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A8E2D3B9E91 for ; Sat, 29 Aug 2020 19:21:11 +0000 (UTC) (envelope-from mason@blisses.org) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bf5sy5TXvz3fcZ for ; Sat, 29 Aug 2020 19:21:10 +0000 (UTC) (envelope-from mason@blisses.org) Received: from cocytus.blisses.org (service.blisses.org [64.223.129.151]) by phlegethon.blisses.org (Postfix) with ESMTP id 2703A194D1A; Sat, 29 Aug 2020 15:21:09 -0400 (EDT) Received: from blisses.org (acheron.int.blisses.org [10.0.1.10]) by cocytus.blisses.org (Postfix) with ESMTPSA id B9289A1; Sat, 29 Aug 2020 15:21:08 -0400 (EDT) Date: Sat, 29 Aug 2020 15:21:07 -0400 From: Mason Loring Bliss To: mike tancsa , Ronald Klop Cc: freebsd-fs@freebsd.org Subject: Re: Maildir on ZFS Message-ID: <20200829192107.GE6456@blisses.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0QFb0wBpEddLcDHQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Bf5sy5TXvz3fcZ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 50.56.97.101 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-5.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[blisses.org]; NEURAL_HAM_LONG(-0.95)[-0.953]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.909]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:19994, ipnet:50.56.0.0/17, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-fs] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 19:21:11 -0000 --0QFb0wBpEddLcDHQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 28, 2020 at 06:45:00PM -0400, mike tancsa wrote: > But I tried on a very busy sftp server where some directories had > 500,000+ files in them.=A0 It didnt seem to make a difference performance > wise for me, at least when fiddling with min cache sizes etc. That's encouraging. I guess that's the anwer - try it and see if there are any observable issues. I've seen lots of complaints about IMAP on IRC and vague noises when searching online, but nothing definitive. Maybe there is nothing definitive. On Sat, Aug 29, 2020 at 10:29:24AM +0200, Ronald Klop wrote: > It depends on the clients also. Do they retrieve mail once, store it > locally and only check the server for updates, than metadata might be > enough, but if it is mostly webmail clients which retrieves the same mail > multiple times, than caching data is probably beneficial. It's mostly Mutt and Thunderbird. I'm not wholly familiar with what Thunderbird does, but Mutt just caches headers and looks for changes. > But it also depends on the amount of data you store on what medium > (HDD/SSD/RAID) and how much memory your server has. Hm? RAID? This'll be ZFS mirrors for this application. Everything I run is either a mirror or raidz2 lately. Lots of memory. Spinning rust. Just ZFS and imapd running in a jail, where the jail has one dataset to itself and doesn't important anything over the network. > NB: Maildir is very (Z)FS friendly by having a lot of static data on disk. > Dovecot creates some indices for fast retrieval of metadata. It'll almost certainly be Dovecot, and that sounds encouraging. (I used to run Courier stuff and that's often tempting, but Dovecot has been pain-free for years now.) > The other advice is: test your own system. In the other reply I saw advice > about how to look at cache statistics. ZFS is very fast without tuning > already. Yar. I was mostly wondering if there were any obvious pitfalls or things that I'm very likely to hit, but it looks like there probably aren't. Once I've got things migrated and seen it in action I'll gather some data and share my results. Thank you both for your input. --=20 Mason Loring Bliss mason@blisses.org They also surf, who only stand on waves. --0QFb0wBpEddLcDHQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAl9Kqp4ACgkQnrJXcHbv JVWK2A//UbqmCHK2nCBpJIRGw3BdtLjWg2NnpNQcT44oZ87scMtetBfSOfwHJk5a xF7iTkYZhOrD7S/jlPHxyK6wo4Y+bfT+oxmMaRMAdgylQ1OXeeFWlBty449Ah2iA 4OKs3A6z7AnuAUzOBbxWOtCUjT3suvlDLTgHSWtDrvYgQdLT/5q7yN4N9dNkNSFb xcbR4zwVJMnOn2xNxP9DrIHAAiIHmMT56z0wBlgswuHkCRff0jB465DM8BnGDNhK U4/nVpfeB6aV5EA2xT/8ULSVFdy4r9Ge+sDnFEVIDK6G7oZfZticBlvZW0KvG4MX 0jWlqBbnTy1tyL7F+Yg/R6Ir4Tlj6ijfpJhet0XVZ1FkKVhlAHmW9tgF3ePFkKuV EpLNBZjtVcz4FnrtKtxhNon28RyoMBN0L9Gl+PWMmIr3EjXuhCVrJtthhNzgEdkd u6IkNsLkaGTdCh+ZQ/oDwrHTBvxtJT1pZWvBuGPgC4n2nnd3UBeUd2+liOIAt3lu DnXZPIOPQeVk6Hz25mn/HCHv8dnZiKbTKVshomWC5wg599Fd7TTCRBkUpnSb5n5Q jS3YDqTzs3AkAmK1aiaFpNOiH3++Vw4bFP6f4KBYk1iHZZOPHU1kLoIeOE5p6kPY kY9ZyJyFoIvUTsBfL8vYCB0TwW0Xj0iw4w4ROrj6qE5ejZ4iBmg= =8/XQ -----END PGP SIGNATURE----- --0QFb0wBpEddLcDHQ--