<html><body>
<p><font size="2" face="sans-serif">Ok,</font><br>
<br>
<font size="2" face="sans-serif">I've now tried to run this on another machine (no hardware in common, save the SSDs), with </font><br>
<font size="2" face="sans-serif">interlopers, still generating checksum errors. I'm using iozone to load it up for testing (I was </font><br>
<font size="2" face="sans-serif">initially asked to do this to demonstrate how much of an improvement we could expect). </font><br>
<br>
<font size="2" face="sans-serif">I was wondering if you guys had any more thoughts or could do a similar test?</font><br>
<br>
<font size="2" face="sans-serif">Andrew Hettinger<br>
<a href="http://Prominic.NET">http://Prominic.NET</a> | Skype: AndrewProminic<br>
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)<br>
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356 (int'l)</font><br>
<br>
<tt><font size="2">"Schweiss, Chip" <chip@innovates.com> wrote on 09/30/2014 07:49:44 AM:<br>
<br>
> From: "Schweiss, Chip" <chip@innovates.com></font></tt><br>
<tt><font size="2">> To: OpenIndiana Developer mailing list <oi-dev@openindiana.org></font></tt><br>
<tt><font size="2">> Date: 09/30/2014 07:58 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [oi-dev] SSD-based pools</font></tt><br>
<tt><font size="2">> <br>
> On Mon, Sep 29, 2014 at 6:14 PM, Andrew M. Hettinger <AHettinger@prominic.net<br>
> > wrote:</font></tt><br>
<tt><font size="2">> Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote on 09/29/2014 <br>
> 05:57:26 PM:<br>
> <br>
> > How would ZFS know if the data stored is "incorrect" from the user's <br>
> > perspective?<br>
> > <br>
> <br>
> Presumably because the checksum is wrong. </font></tt><br>
<tt><font size="2">> <br>
> Exactly, if the data is returned incorrect from the SSD ZFS will <br>
> detect it via checksum. It will then rebuild from the raidz1 <br>
> parity, if that fails it will return a data read error.</font></tt><br>
<tt><font size="2">> <br>
> In relation to the original topic, with 163 days uptime, the scratch<br>
> pool has had zero checksum errors. It gets completely rewritten <br>
> about twice a week on average. At its peak usage it was rewritten <br>
> daily for about 45 days.<br>
> <br>
> root@hcp-iops1:~# uptime<br>
> 07:44am up 163 days 20:57, 1 user, load average: 0.13, 0.15, 0.16<br>
> root@hcp-iops1:~# zpool status scratch<br>
> pool: scratch<br>
> state: ONLINE<br>
> scan: scrub repaired 0 in 7h59m with 0 errors on Sat Sep 6 00:59:21 2014<br>
> config:<br>
> <br>
> NAME STATE READ WRITE CKSUM<br>
> scratch ONLINE 0 0 0<br>
> raidz1-0 ONLINE 0 0 0<br>
> c1t500253855035D1B1d0s0 ONLINE 0 0 0<br>
> c1t500253855035D12Fd0s0 ONLINE 0 0 0<br>
> c1t500253855035D114d0s0 ONLINE 0 0 0<br>
> c1t500253855035D10Ed0s0 ONLINE 0 0 0<br>
> c1t500253855035D109d0s0 ONLINE 0 0 0<br>
> raidz1-1 ONLINE 0 0 0<br>
> c1t500253855035D1C1d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1C0d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1BFd0s0 ONLINE 0 0 0<br>
> c1t500253855035D1BEd0s0 ONLINE 0 0 0<br>
> c1t500253855035D1B5d0s0 ONLINE 0 0 0<br>
> raidz1-2 ONLINE 0 0 0<br>
> c1t500253855035D1E3d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1E1d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1C8d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1C6d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1C3d0s0 ONLINE 0 0 0<br>
> raidz1-3 ONLINE 0 0 0<br>
> c1t500253855035D8C0d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8BDd0s0 ONLINE 0 0 0<br>
> c1t500253855035D1F6d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1E6d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1E5d0s0 ONLINE 0 0 0<br>
> raidz1-4 ONLINE 0 0 0<br>
> c1t500253855035D8C7d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C6d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C3d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C2d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C1d0s0 ONLINE 0 0 0<br>
> raidz1-5 ONLINE 0 0 0<br>
> c1t500253855035E2F6d0s0 ONLINE 0 0 0<br>
> c1t500253855035E2F5d0s0 ONLINE 0 0 0<br>
> c1t500253855035E2ECd0s0 ONLINE 0 0 0<br>
> c1t500253855035E2EBd0s0 ONLINE 0 0 0<br>
> c1t500253855035E2D7d0s0 ONLINE 0 0 0<br>
> raidz1-6 ONLINE 0 0 0<br>
> c1t500253855035F484d0s0 ONLINE 0 0 0<br>
> c1t500253855035F483d0s0 ONLINE 0 0 0<br>
> c1t500253855035F480d0s0 ONLINE 0 0 0<br>
> c1t500253855035F472d0s0 ONLINE 0 0 0<br>
> c1t500253855035F46Fd0s0 ONLINE 0 0 0<br>
> raidz1-7 ONLINE 0 0 0<br>
> c1t5002538550363742d0s0 ONLINE 0 0 0<br>
> c1t500253855036373Ed0s0 ONLINE 0 0 0<br>
> c1t50025385503633BDd0s0 ONLINE 0 0 0<br>
> c1t5002538550363164d0s0 ONLINE 0 0 0<br>
> c1t500253855035F489d0s0 ONLINE 0 0 0<br>
> raidz1-8 ONLINE 0 0 0<br>
> c1t500253855036378Ad0s0 ONLINE 0 0 0<br>
> c1t5002538550363789d0s0 ONLINE 0 0 0<br>
> c1t5002538550363786d0s0 ONLINE 0 0 0<br>
> c1t500253855036374Cd0s0 ONLINE 0 0 0<br>
> c1t500253855036374Bd0s0 ONLINE 0 0 0<br>
> raidz1-9 ONLINE 0 0 0<br>
> c1t500253855035D1F4d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1ECd0s0 ONLINE 0 0 0<br>
> c1t500253855035D1E2d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1DAd0s0 ONLINE 0 0 0<br>
> c1t500253855035D1B2d0s0 ONLINE 0 0 0<br>
> raidz1-10 ONLINE 0 0 0<br>
> c1t500253855035D12Dd0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C8d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C5d0s0 ONLINE 0 0 0<br>
> c1t500253855035D8C4d0s0 ONLINE 0 0 0<br>
> c1t500253855035D1F8d0s0 ONLINE 0 0 0<br>
> raidz1-11 ONLINE 0 0 0<br>
> c1t5002538550363793d0s0 ONLINE 0 0 0<br>
> c1t500253855035E2DBd0s0 ONLINE 0 0 0<br>
> c1t500253855035E2DAd0s0 ONLINE 0 0 0<br>
> c1t500253855035E2D9d0s0 ONLINE 0 0 0<br>
> c1t500253855035D12Ed0s0 ONLINE 0 0 0<br>
> spares<br>
> c1t5002538550363794d0s0 AVAIL<br>
> c1t5002538550363797d0s0 AVAIL<br>
> c1t500253855035E2D8d0s0 AVAIL<br>
> <br>
> errors: No known data errors_______________________________________________<br>
> oi-dev mailing list<br>
> oi-dev@openindiana.org<br>
> <a href="http://openindiana.org/mailman/listinfo/oi-dev">http://openindiana.org/mailman/listinfo/oi-dev</a></font></tt></body></html>