From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 09:18:56 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AC19364 for ; Tue, 24 Feb 2015 09:18:56 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 5143B6EC for ; Tue, 24 Feb 2015 09:18:56 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YQBdk-000FEo-Fq; Tue, 24 Feb 2015 12:18:52 +0300 Date: Tue, 24 Feb 2015 12:18:52 +0300 From: Slawa Olhovchenkov To: "Frank de Bot (lists)" Subject: Re: ZFS L2arc 16.0E size Message-ID: <20150224091852.GA55016@zxy.spb.ru> References: <54E1388C.3060602@searchy.net> <54E13F41.7000703@multiplay.co.uk> <20150222212135.GA64559@zxy.spb.ru> <20150223172452.GA44463@zxy.spb.ru> <54EBAA46.1020705@searchy.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EBAA46.1020705@searchy.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 09:18:56 -0000 On Mon, Feb 23, 2015 at 11:31:34PM +0100, Frank de Bot (lists) wrote: > Slawa Olhovchenkov wrote: > > On Mon, Feb 23, 2015 at 12:21:35AM +0300, Slawa Olhovchenkov wrote: > > > >> On Mon, Feb 16, 2015 at 12:52:17AM +0000, Steven Hartland wrote: > >> > >>> IIRC this was fixed by r273060, if your remove your cache device and > >>> then add it back I think you should be good. > >> > >> r273060 will be reverted. > >> I am use stable (r276179) and still have (partialy) this problem: > >> > >> cache - - - - - - > >> ada0 477G 477G 16.0E - 0% 100% > >> ada1 477G 477G 16.9M - 0% 99% > >> da2 477G 477G 25.0M - 0% 99% > >> da3 477G 477G 14.6M - 0% 99% > >> da4 477G 477G 30.6M - 0% 99% > >> da5 477G 477G 15.0M - 0% 99% > >> da6 477G 477G 298K - 0% 99% > >> da7 477G 477G 18.2M - 0% 99% > > > > same server, some time late: > > cache - - - - - - > > ada0 477G 477G 16.8M - 0% 99% > > ada1 477G 477G 32.1M - 0% 99% > > da2 477G 477G 5.70M - 0% 99% > > da3 477G 477G 16.0E - 0% 100% > > da4 477G 477G 26.1M - 0% 99% > > da5 477G 477G 26.6M - 0% 99% > > da6 477G 477G 16.0E - 0% 100% > > da7 477G 477G 16.0E - 0% 100% > > > > hmm, -p don't affect -v values. > > Tonight I had run some tests: > - Disabling compression (by changing ZIO_COMPRESS_LZ4 to > ZIO_COMPRESS_OFF in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > in l2arc_compress_buf > - disabling trim by vfs.zfs.trim.enabled=0 in loader.conf > - trying to prevent io queues, but I don't think this was good. I was > thinking there maybe is a possibility that between filling a writebuffer > for a vdev the size of l2arc was checked, but didn't take in account > that not all data is there (I really don't have a clue if this makes > any sense) > > None of these test were successful, every time free space is 16.0E and > used space keeps on growing and growing. > > Slawa, I do notice that first ada0 was at 16.0E, but at your second post > not anymore. Yes, I see too and do second post for this. I think this is may be error on output (not for internal structure as past), but -p key don't work for this values and I can't recalculate bu hands.