<div dir="ltr"><div>I have tested FusionIO together with old thick snapshots.</div><div>I created the thick snapshot on a separate old traditional SATA drive, just to check if that could be used as a snapshot target for high performance disks; like a Fusion IO card.</div><div>For those who doesn't know about FusionIO; they can deal with 150-250,000 IOPS.<br></div><div><br></div><div>And to be honest, I couldn't bottle neck the SATA disk I used as a thick snapshot target.</div><div>The reason for why is simple:</div><div>- thick snapshots uses sequential write techniques</div><div><br></div><div>If I would have been using thin snapshots, than the writes would most likely be more randomized on disk, which would have required more spindles to coop with this.</div><div><br></div><div>Anyhow;</div><div>I am still eager to hear how to use an external device to import snapshots.</div><div>And when I say "import"; I am not talking about copyback, more to use to read data from.</div><div><br></div><div>Regards Tomas</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">Den ons 23 okt. 2019 kl 13:08 skrev Gionatan Danti <<a href="mailto:g.danti@assyoma.it">g.danti@assyoma.it</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">On 23/10/19 12:46, Zdenek Kabelac wrote:<br>
> Just few 'comments' - it's not really comparable - the efficiency of <br>
> thin-pool metadata outperforms old snapshot in BIG way (there is no <br>
> point to talk about snapshots that takes just couple of MiB)<br>
<br>
Yes, this matches my experience.<br>
<br>
> There is also BIG difference about the usage of old snapshot origin and <br>
> snapshot.<br>
> <br>
> COW of old snapshot effectively cuts performance 1/2 if you write to <br>
> origin.<br>
<br>
If used without non-volatile RAID controller, 1/2 is generous - I <br>
measured performance as low as 1/5 (with fat snapshot).<br>
<br>
Talking about thin snapshot, an obvious performance optimization which <br>
seems to not be implemented is to skip reading source data when <br>
overwriting in larger-than-chunksize blocks.<br>
<br>
For example, consider a completely filled 64k chunk thin volume (with <br>
thinpool having ample free space). Snapshotting it and writing a 4k <br>
block on origin will obviously cause a read of the original 64k chunk, <br>
an in-memory change of the 4k block and a write of the entire modified <br>
64k block to a new location. But writing, say, a 1 MB block should *not* <br>
cause the same read on source: after all, the read data will be <br>
immediately discarded, overwritten by the changed 1 MB block.<br>
<br>
However, my testing shows that source chunks are always read, even when <br>
completely overwritten.<br>
<br>
Am I missing something?<br>
<br>
-- <br>
Danti Gionatan<br>
Supporto Tecnico<br>
Assyoma S.r.l. - <a href="http://www.assyoma.it" target="_blank" rel="noreferrer">www.assyoma.it</a><br>
email: <a href="mailto:g.danti@assyoma.it" target="_blank">g.danti@assyoma.it</a> - <a href="mailto:info@assyoma.it" target="_blank">info@assyoma.it</a><br>
GPG public key ID: FF5F32A8<br>
</blockquote></div>