Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Nov 2015 23:53:10 +0100
From:      Kai Gallasch <k@free.de>
To:        kpneal@pobox.com, krad <kraduk@gmail.com>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: High fragmentation on zpool log
Message-ID:  <565CD356.3010108@free.de>
In-Reply-To: <20151130160949.GA7354@neutralgood.org>
References:  <565875A7.6060004@free.de> <CALfReycnyrH3rSAwUUCJGp9BVSC6TgJ=0TrYNh4P-=o8p==8Ew@mail.gmail.com> <20151130160949.GA7354@neutralgood.org>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
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.
> 
> Well, all of this is true, but I'm not convinced that was the real question.
> My interpretation was that the OP was asking how a log device 8GB in size
> 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 seconds
> 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 faster?

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.

-- 
PGP-KeyID = 0x70654D7C4FB1F588




[-- Attachment #2 --]
-----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-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?565CD356.3010108>