High fragmentation on zpool log

Tue Dec 1 09:48:28 UTC 2015

> Kai Gallasch <k at free.de> hat am 30. November 2015 um 23:53 geschrieben:
>
>
> On 30.11.2015 17:09 kpneal at 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?

afaik thats a side effect from l2arc compression. i´ve seen this on freebsd &
illumos as well. but it went away with some updates durinjg the last 2-3 months
or so. not sure, but if i remember correctly there was something related to this
and data corruption caused by a bug in the l2arc compression (afaik only illumos
distros where affected by corruption).

>
> Kai.
>
> --
> PGP-KeyID = 0x70654D7C4FB1F588
>
>
>