<div>I read the source code of 'dm_suspend' in the kernel, find it will call this function:</div>
<div> </div>
<div>__filemap_fdatawrite(mapping, <font color="#ff0000">WB_SYNC_ALL</font>);</div>
<div> </div>
<div>so I understand </div>
<div>"I don't think it is possible to suspend new IO requests from user land<br>while allowing it from the buffer cache" </div>
<div>you said.</div>
<div>Thank you very much, :)</div>
<div> </div>
<div>Best regards,</div>
<div>Busby<br></div>
<div class="gmail_quote">2010/4/30 Phillip Susi <span dir="ltr"><<a href="mailto:psusi@cfl.rr.com">psusi@cfl.rr.com</a>></span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On 4/29/2010 9:09 PM, Busby wrote:<br>> Hi, Phillip Susi,<br>>                  Why not suspend the origin's IO first, then create the<br>> snapshot lv, resume the origin lv 's IO waiting Q last. the 'dd' cmd is<br>
> eariler than the snapshot's creating, if suspend the IO, the filesystem<br>> on the snapshot will be corrupt, I get it, but I think the  snapshot is<br>> in block layer, should suspend the user layer's data coming first, then<br>
> flush the data in the dirty buffer and create the snapshot.  like the dd<br>> cmd on the origin, will make the snapshot's creating take a very long<br>> time, for waiting for the dm suspend 's return, I think flush the data<br>
> in the dirty buffer (data from dd ), suspend the next data of the dd,<br>> create the snapshot, then let the data into dirty buffer to the block<br>> layer. the dd cmd will put the data into dirty buffer continually, can<br>
> not be suspended?<br><br></div>I don't think it is possible to suspend new IO requests from user land<br>while allowing it from the buffer cache.<br></blockquote></div><br>