FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 04-30-2010, 01:09 AM
Busby
 
Default create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)

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?

********
*
Best regards,
Bubsy


2010/4/30 Phillip Susi <psusi@cfl.rr.com>


On 4/28/2010 11:24 PM, Busby wrote:
> it seems the vgs suspend because the lvcreate cmd don't unlock the
> flock, but why the lvcreating of snapshot lv will be suspended while the
> origin is on big data IO?


Because when creating a snapshot it tries to flush any dirty buffers so
that the origin is in a consistent state at the time the snapshot is
created. *This is done to minimize the chance that the filesystem on the

snapshot will be corrupt.


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-05-2010, 11:10 AM
Busby
 
Default create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)

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@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.


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 09:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org