From owner-freebsd-current@FreeBSD.ORG Mon Oct 21 08:26:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D96D7799; Mon, 21 Oct 2013 08:26:25 +0000 (UTC) (envelope-from prvs=1006428abc=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FE8A2362; Mon, 21 Oct 2013 08:26:25 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006466375.msg; Mon, 21 Oct 2013 09:26:17 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 21 Oct 2013 09:26:17 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1006428abc=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6917E0AC86C444EFB3B55750175BADED@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" References: <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> <20131018080148.GA75226@hell.ukr.net> <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> <20131018144524.GA30018@hell.ukr.net> <4459A6FAB7B8445C97CCB9EFF34FD4F0@multiplay.co.uk> <20131019085547.GA33582@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Mon, 21 Oct 2013 09:26:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Vitalij Satanivskij , "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 08:26:26 -0000 Hows things looking Vitalij? ----- Original Message ----- From: "Vitalij Satanivskij" > Ok. Just right now system rebooted with you patch. > > Trim enabled again. > > WIll wait some time untile size of used cache grow's. > > > Steven Hartland wrote: > SH> Looking at the l2arc compression code I believe that metadata is always > SH> compressed with lz4, even if compression is off on all datasets. > SH> > SH> This is backed up by what I'm seeing on my system here as it shows a > SH> non-zero l2_compress_successes value even though I'm not using > SH> compression at all. > SH> > SH> I think we we may well need the following patch to set the minblock > SH> size based on the vdev ashift and not SPA_MINBLOCKSIZE. > SH> > SH> svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > SH> Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > SH> =================================================================== > SH> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision 256554) > SH> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy) > SH> @@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr) > SH> len = l2hdr->b_asize; > SH> cdata = zio_data_buf_alloc(len); > SH> csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr->b_tmp_cdata, > SH> - cdata, l2hdr->b_asize, (size_t)SPA_MINBLOCKSIZE); > SH> + cdata, l2hdr->b_asize, (size_t)(1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift)); > SH> > SH> if (csize == 0) { > SH> /* zero block, indicate that there's nothing to write */ > SH> > SH> Could you try this patch on your system Vitalij see if it has any effect > SH> on the number of l2_cksum_bad / l2_io_error? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.