<div dir="ltr"><pre style="color:rgb(0,0,0)">Hi Mike,</pre><pre style="color:rgb(0,0,0)">Thank you a lot for your very fast response. I'll backport <span style="font-family:arial"> commit e0d849fad7 to 3.11.10 and will let you know how dm-cache behaves on large cache SSD. Probably I will check the code for other truncation issues.</span></pre>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 4:01 PM, Mike Snitzer <span dir="ltr"><<a href="mailto:snitzer@redhat.com" target="_blank">snitzer@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Mar 17 2014 at  9:43am -0400,<br>
George . <<a href="mailto:george@ucdn.com">george@ucdn.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> In dm-3.14-fixes-4, there is a description that :<br>
><br>
> - fix corruption with >2TB fast device due to truncation bug<br>
> But looking at the diffidence I can't find anything related to such bug.<br>
<br>
</div>Commit 8b9d96666529 ("dm cache: fix truncation bug when copying a block<br>
to/from >2TB fast device") follows the same pattern as commit e0d849fad7<br>
("dm cache: fix truncation bug when mapping I/O to >2TB fast device").<br>
Which is that from_cblock() only returns a 32bit value, so any 64bit<br>
math operation must use a type that can accomodate 64bit.  That is why<br>
an intermediate sector_t value is now used in both commits.<br>
<div class=""><br>
> I'm asking this, because we are trying to use dm-cache on machine with 2.4<br>
> TB SDD cache and after I took following fix:<br>
><br>
> dm-3.14-fixes-1<br>
> dm cache: fix truncation bug when mapping I/O to >2TB fast device<br>
</div>> dm-3.14-fixes-1<<a href="http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/tag/?id=dm-3.14-fixes-1" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/tag/?id=dm-3.14-fixes-1</a>><br>

<div class="">><br>
> our cached device got corrupted again.<br>
<br>
</div>Commit e0d849fad7 wouldn't have been the cause.  If you didn't also<br>
apply 8b9d96666529 then you could have hit that one.<br>
<div class=""><br>
> My question is: is there another truncation bug discovered?<br>
<br>
</div>Yeah, both the above referenced commits (commit 8b9d96666529 being the<br>
most recent).<br>
<div class=""><br>
> I've back ported  dm-3.14-fixes-1 to 3.11.10 kernel, because when we tested<br>
</div>> v3.14-rc5<<a href="http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/tag/?id=v3.14-rc5" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/tag/?id=v3.14-rc5</a>><br>

<div class="">> -<br>
> cached device was corrupted after ~15 minutes and seems to be more<br>
> unstable.<br>
<br>
</div>OK, well upstream dm-cache saw very little change for 3.14.  Just a<br>
handful of bug fixes.  So you're likely hitting an outstanding bug that<br>
we've yet to fix.  One issue that is being actively pursued is the<br>
thought that discards could be contributing to corruption.  Heinz will<br>
have an update on this line of discovery soon.<br>
</blockquote></div><br></div>