Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Dec 2015 10:48:13 +0100 (CET)
From:      InterNetX - Juergen Gotteswinter <jg@internetx.com>
To:        Kai Gallasch <k@free.de>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: High fragmentation on zpool log
Message-ID:  <598756590.434.8607f2eb-aa36-44cc-ba27-77d495c7da6d.open-xchange@ox.internetx.com>
In-Reply-To: <565CD356.3010108@free.de>
References:  <565875A7.6060004@free.de> <CALfReycnyrH3rSAwUUCJGp9BVSC6TgJ=0TrYNh4P-=o8p==8Ew@mail.gmail.com> <20151130160949.GA7354@neutralgood.org> <565CD356.3010108@free.de>

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

> Kai Gallasch <k@free.de> hat am 30. November 2015 um 23:53 geschrieben:
>
>
> 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 t=
he
> >> 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 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?
=20
afaik thats a side effect from l2arc compression. i=C2=B4ve seen this on fr=
eebsd &
illumos as well. but it went away with some updates durinjg the last 2-3 mo=
nths
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 il=
lumos
distros where affected by corruption).
=20

>
> Kai.
>
> --
> PGP-KeyID =3D 0x70654D7C4FB1F588
>
>
>
From owner-freebsd-fs@freebsd.org  Tue Dec  1 11:29:42 2015
Return-Path: <owner-freebsd-fs@freebsd.org>
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 9DFECA3C23F
 for <freebsd-fs@mailman.ysv.freebsd.org>; Tue,  1 Dec 2015 11:29:42 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
 [IPv6:2001:1900:2254:206a::16:76])
 (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 89D0D1185
 for <freebsd-fs@FreeBSD.org>; Tue,  1 Dec 2015 11:29:42 +0000 (UTC)
 (envelope-from bugzilla-noreply@freebsd.org)
Received: from bugs.freebsd.org ([127.0.1.118])
 by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB1BTgQ9046794
 for <freebsd-fs@FreeBSD.org>; Tue, 1 Dec 2015 11:29:42 GMT
 (envelope-from bugzilla-noreply@freebsd.org)
From: bugzilla-noreply@freebsd.org
To: freebsd-fs@FreeBSD.org
Subject: [Bug 194513] zfs recv hangs in state kmem arena
Date: Tue, 01 Dec 2015 11:29:40 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 10.0-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: smh@FreeBSD.org
X-Bugzilla-Status: Open
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-194513-3630-QEI77AhJna@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-194513-3630@https.bugs.freebsd.org/bugzilla/>
References: <bug-194513-3630@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>;
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 11:29:42 -0000

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513

Steven Hartland <smh@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #148687|0                           |1
        is obsolete|                            |

--- Comment #15 from Steven Hartland <smh@FreeBSD.org> ---
Created attachment 163702
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163702&action=edit
utility to allocate memory to force defragmentation

This is a little utility that allocates memory, which creates memory pressure
in an attempt to force de-fragmentation as ARC free's up aggressively.

Its based on James Van Artsdalen initial utility with fixes for compilation as
well as adding progress output and unbounding the allocation which is now done
in 1GB chunks.

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?598756590.434.8607f2eb-aa36-44cc-ba27-77d495c7da6d.open-xchange>