High fragmentation on zpool log

[Kai Gallasch]

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?

Kai.

-- 
PGP-KeyID = 0x70654D7C4FB1F588



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20151130/12c68ea6/attachment.bin>