From owner-freebsd-fs@freebsd.org Mon Nov 30 22:53:19 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D54FFA3DABA for ; Mon, 30 Nov 2015 22:53:19 +0000 (UTC) (envelope-from k@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (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 1DB3F132A for ; Mon, 30 Nov 2015 22:53:18 +0000 (UTC) (envelope-from k@free.de) Received: (qmail 3272 invoked from network); 30 Nov 2015 23:53:10 +0100 Received: from smtp.free.de (HELO [91.204.7.46]) (k@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 30 Nov 2015 23:53:10 +0100 Subject: Re: High fragmentation on zpool log To: kpneal@pobox.com, krad References: <565875A7.6060004@free.de> <20151130160949.GA7354@neutralgood.org> Cc: FreeBSD FS From: Kai Gallasch X-Enigmail-Draft-Status: N1110 Organization: FREE! Message-ID: <565CD356.3010108@free.de> Date: Mon, 30 Nov 2015 23:53:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151130160949.GA7354@neutralgood.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wiUTfqigaX0vUbVUjbfiaoKeWOuGlHRrH" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:53:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wiUTfqigaX0vUbVUjbfiaoKeWOuGlHRrH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30.11.2015 17:09 kpneal@pobox.com wrote: > On Mon, Nov 30, 2015 at 09:17:33AM +0000, krad wrote: >> Fragmentation isn't really a big issue on SSD's as there are no heads = to >> move around like on magnetic drives. Also due to wear levelling, you >> actually have no idea where a block actually is on a memory cell, as= the >> drive only gives a logical representation of the layout of blocks, not= an >> actual true mapping. >=20 > Well, all of this is true, but I'm not convinced that was the real ques= tion. > My interpretation was that the OP was asking how a log device 8GB in si= ze > can get to be 85% fragmented. Yes. I am wondering why fragmentation with a more than sufficient size of the log and given the high throughput of SSDs is happening at all. Maybe because the log and cache are on the same pair of SSDs? > My guess was that 85% fragmentation of a log device may be a sign of a = log > device that is too small. But I thought log devices only held a few sec= onds > of activity, so I'm a little confused about how a log device can get to= > be 85% fragmented. Is this pool really moving a gigabyte a second or fa= ster? No, far from that. The pool is mostly read from and is used for local storage of roundabout 50 jails. The write rate of the log is in the region < 20 MB/s ave. >>> cache - - - - - >>> gpt/cache-BTTV5234003K100FGN 85.2G 142G 16.0E 0% 166% >>> gpt/cache-BTTV523401U4100FGN 85.2G 172G 16.0E 0% 202% Any theories why zpool list -v shows so funny values for FREE and CAP of the cache? Kai. --=20 PGP-KeyID =3D 0x70654D7C4FB1F588 --wiUTfqigaX0vUbVUjbfiaoKeWOuGlHRrH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJWXNNWAAoJEHBlTXxPsfWIRKwQAJkY+5j/eXS/x+uk7ot2mviB BMCHV/Jls9fme6mW6ryjRGE8FiFvwRigixy+5b6GkHsYHMtoRYE09+DYp291ph8/ MsbXqbKDMSuG6NwU4SUkQkrAe0yQUGRCpWOb0qxIqIcJ0GWeeu9SIVy61CFTlb5u WLei1YRY3ntxpcs/JRqefR8sbVTu51OjFxkBVbMgeYZZsgS4OWZY6mH0CCgrI59F 4jhIC5hbemJ8MgW4sOPTLH+GaX00RPLN52rB8GQ+X2NZpcFhgP/6KkV0junc/fI2 ZvRvpSRwWUjAoH26mOkaiQok+he9KKUTIhBvRez+qEn0J6dGEeLIBd6EhEZSlMsl 2ZTQ8nqUgylD2Vg44m1KZVYYFs7W2xN35uzlurOFDQxZ/IDyACrG6R62KjtSyttQ z9IU7wKIqPHEeenQdeeNEnWp6hqkJaauDaMGl4S5XnPMFuKNbuQWQTsKAM0dca1k AlMPnA5dGojruHNHArSVRn+m3aGtN1V+KKK/3oqVEUP2RFaUnfeXbGSV3MF9Bj1U 2RhfawVkgjjKBE+GaNMzRtf/ePAE/ohhrA5HN65autyhhiaMFiVXQDWs1nnsWA84 8BQLnvCSemZ0H6+5WqjlzynRbjBsAkZBN9T1DkLLdZy25oD4LyBAH0Cg54Aw1/0D Zs29k7vCtStMRTOX7beL =W04V -----END PGP SIGNATURE----- --wiUTfqigaX0vUbVUjbfiaoKeWOuGlHRrH--