Date: Mon, 21 Oct 2013 15:32:12 +0300 From: Vitalij Satanivskij <satan@ukr.net> To: Steven Hartland <killing@multiplay.co.uk> Cc: Vitalij Satanivskij <satan@ukr.net>, Dmitriy Makarov <supportme@ukr.net>, "Justin T. Gibbs" <gibbs@FreeBSD.org>, Borja Marcos <borjam@sarenet.es>, freebsd-current@freebsd.org Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131021123212.GA11886@hell.ukr.net> In-Reply-To: <6917E0AC86C444EFB3B55750175BADED@multiplay.co.uk> References: <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> <6917E0AC86C444EFB3B55750175BADED@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Just now I cannot say, as to triger problem we need at last 200+gb size on l2arc wich usually grow in one production day.
But for some reason today in the morning server was rebooted so cache was flushed and now only 100Gb.
Need to wait some more time.
At last for now none error on l2.
Steven Hartland wrote:
SH> Hows things looking Vitalij?
SH>
SH> ----- Original Message -----
SH> From: "Vitalij Satanivskij" <satan@ukr.net>
SH>
SH>
SH> > Ok. Just right now system rebooted with you patch.
SH> >
SH> > Trim enabled again.
SH> >
SH> > WIll wait some time untile size of used cache grow's.
SH> >
SH> >
SH> > Steven Hartland wrote:
SH> > SH> Looking at the l2arc compression code I believe that metadata is always
SH> > SH> compressed with lz4, even if compression is off on all datasets.
SH> > SH>
SH> > SH> This is backed up by what I'm seeing on my system here as it shows a
SH> > SH> non-zero l2_compress_successes value even though I'm not using
SH> > SH> compression at all.
SH> > SH>
SH> > SH> I think we we may well need the following patch to set the minblock
SH> > SH> size based on the vdev ashift and not SPA_MINBLOCKSIZE.
SH> > SH>
SH> > SH> svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
SH> > SH> Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
SH> > SH> ===================================================================
SH> > SH> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision 256554)
SH> > SH> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy)
SH> > SH> @@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr)
SH> > SH> len = l2hdr->b_asize;
SH> > SH> cdata = zio_data_buf_alloc(len);
SH> > SH> csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr->b_tmp_cdata,
SH> > SH> - cdata, l2hdr->b_asize, (size_t)SPA_MINBLOCKSIZE);
SH> > SH> + cdata, l2hdr->b_asize, (size_t)(1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift));
SH> > SH>
SH> > SH> if (csize == 0) {
SH> > SH> /* zero block, indicate that there's nothing to write */
SH> > SH>
SH> > SH> Could you try this patch on your system Vitalij see if it has any effect
SH> > SH> on the number of l2_cksum_bad / l2_io_error?
SH>
SH>
SH> ================================================
SH> 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.
SH>
SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
SH> or return the E.mail to postmaster@multiplay.co.uk.
SH>
SH> _______________________________________________
SH> freebsd-current@freebsd.org mailing list
SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current
SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131021123212.GA11886>