create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
 

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

create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
 

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