Hi Joe,

2016-06-24 21:55 GMT+08:00 Edward Thornber <thornber@redhat.com>:

Hi Dennis,

On Tue, Jun 21, 2016 at 03:56:26PM +0800, Dennis Yang wrote:
> So my question is, does dm-thin have any mechanism to eliminate the ra= ce
> when
> discarded block is reused right away by another device?

I'll try and recreate your scenario.=C2=A0 The transaction-manag= er will not
reallocate a block that's been freed within a transaction so that we can always rollback.=C2=A0 So as long as there hasn't been a commit, reallocation shouldn't be possible.=C2=A0 This is what normally guards<= br> allocation, but in your case I think you may be onto something and we
may have to hold onto the data cell until the passdown discards are
complete.

- Joe

In my experience, this issue is pretty hard to repro= duce solely by a thin-pool=C2=A0

which is b= uilt on top of a regular hard disk or RAID, since I rarely observe the=C2= =A0

DISCARD and WRITE coming from different= thin devices get reordered in the=C2=A0

lo= wer level. In my system, the thin-pool is built on top of another device-ma= pper=C2=A0

device providing data tiering fu= nctionality which could delay the DISCARD=C2=A0

request a little bit and lead to a request reorder situation.=C2=A0

Based on= the log I had, I suspect that there was metadata commit before another

thin device reused the discarded block while t= he DISCARD request was still being

processe= d by the lower level stacks. In this case, holding the data cell until the= =C2=A0

passdown discards are complete seems= to only protect the discarded block from

b= eing reallocated by the same thin device which allocates the block in the f= irst place,

because only those write I/Os t= hat are going to the same device will be prisoned.=C2=A0

In my opinion, I think m= aybe the to-be-discard block should only be freed after the

passdown discards have been complete. I had only written a= patch in this way and=C2=A0

applied it on = my site since last week, and the issue had not been seen on my site=C2=A0

for 72 hours. I am not very confident about = whether this patch will cause any side

effe= ct, I would be highly appreciated if you can share your concern with me.

Thanks f= or your reply,

Dennis =C2=A0=C2=A0

=C2=A0 =C2=A0

<= br>

Dennis Yang=C2=A0=C2=A0
QNAP Syst= ems, Inc.

Skype: qnap.dennis.yang
Email:=C2=A0 dennisyang@qnap.com

Tel:=C2=A0(+886)-2-2393-5152 ext.=C2=A015018

Address:=C2=A013F., No.56, Sec. 1, Xi= nsheng S. Rd., Zhongzheng Dist., Taipei City, Taiwan

--047d7bb049c67f3d0405363f342e-- --===============5457158760609248397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5457158760609248397==--