[dm-devel] create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)

Busby chaimvy at gmail.com
Wed May 5 11:10:08 UTC 2010


I read the source code of 'dm_suspend' in the kernel, find it will call this
function:

__filemap_fdatawrite(mapping, WB_SYNC_ALL);

so I understand
"I don't think it is possible to suspend new IO requests from user land
while allowing it from the buffer cache"
you said.
Thank you very much, :)

Best regards,
Busby
2010/4/30 Phillip Susi <psusi at cfl.rr.com>

> On 4/29/2010 9:09 PM, Busby wrote:
> > Hi, Phillip Susi,
> >                  Why not suspend the origin's IO first, then create the
> > snapshot lv, resume the origin lv 's IO waiting Q last. the 'dd' cmd is
> > eariler than the snapshot's creating, if suspend the IO, the filesystem
> > on the snapshot will be corrupt, I get it, but I think the  snapshot is
> > in block layer, should suspend the user layer's data coming first, then
> > flush the data in the dirty buffer and create the snapshot.  like the dd
> > cmd on the origin, will make the snapshot's creating take a very long
> > time, for waiting for the dm suspend 's return, I think flush the data
> > in the dirty buffer (data from dd ), suspend the next data of the dd,
> > create the snapshot, then let the data into dirty buffer to the block
> > layer. the dd cmd will put the data into dirty buffer continually, can
> > not be suspended?
>
> I don't think it is possible to suspend new IO requests from user land
> while allowing it from the buffer cache.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20100505/aac84782/attachment.htm>


More information about the dm-devel mailing list