From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Susi Subject: Re: create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends) Date: Fri, 30 Apr 2010 10:39:12 -0400 Message-ID: <4BDAEB90.7050305@cfl.rr.com> References: <4BD9C264.7040501@cfl.rr.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Busby Cc: device-mapper development List-Id: dm-devel.ids 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.