ZFS secondarycache on SSD problem on r255173

[Steven Hartland]

Hmm so that rules out a TRIM related issue. I wonder if the
increase in ashift has triggered a problem in compression.

What are all the values reported by:
sysctl -a kstat.zfs.misc.arcstats

    Regards
    Steve

----- Original Message ----- 
From: "Vitalij Satanivskij" <satan at ukr.net>
To: "Steven Hartland" <killing at multiplay.co.uk>
Cc: <satan at ukr.net>; "Justin T. Gibbs" <gibbs at FreeBSD.org>; <freebsd-current at freebsd.org>; "Borja Marcos" <borjam at sarenet.es>; 
"Dmitriy Makarov" <supportme at ukr.net>
Sent: Friday, October 18, 2013 9:01 AM
Subject: Re: ZFS secondarycache on SSD problem on r255173


> Hello.
>
> Yesterday system was rebooted with vfs.zfs.trim.enabled=0
>
> System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code
>
> Uptime 10:51  up 16:41
>
> sysctl vfs.zfs.trim.enabled
> vfs.zfs.trim.enabled: 0
>
> Around 2 hours ago errors counter's
> kstat.zfs.misc.arcstats.l2_cksum_bad: 854359
> kstat.zfs.misc.arcstats.l2_io_error: 38254
>
> begin grow from zero values.
>
> After remove cache
> 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2
>
> and attach again
>
> 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2
>
> counters stop growing (of couse thay not zeroed)
>
> before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB
>
> hw size of l2 cache is 3x164G
>
> =>       34  351651821  ada3  GPT  (168G)
>         34          6        - free -  (3.0K)
>         40    8388608     1  zil2  (4.0G)
>    8388648  343263200     2  cache2  (164G)
>  351651848          7        - free -  (3.5K)
>
>
> Any hypothesis what alse we can test/try etc?
>
>
>
> Steven Hartland wrote:
> SH> Correct.
> SH> ----- Original Message ----- 
> SH> From: "Vitalij Satanivskij" <satan at ukr.net>
> SH>
> SH>
> SH> > Just to be sure I understand you clearly, I need to test next configuration:
> SH> >
> SH> > 1) System with ashift patch eg. just latest stable/10 revision
> SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf
> SH> >
> SH> > So realy only diferens in default system configuration is  disabled trim functional ?
> SH> >
> SH> >
> SH> >
> SH> > Steven Hartland wrote:
> SH> > SH> Still worth testing with the problem version installed but
> SH> > SH> with trim disabled to see if that clears the issues, if
> SH> > SH> nothing else it will confirm / deny if trim is involved.
> 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 at multiplay.co.uk.
> SH>
> SH> _______________________________________________
> SH> freebsd-current at freebsd.org mailing list
> SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 


================================================
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 at multiplay.co.uk.