[dm-devel] How to block IO coming from filesystem while mapping bh?

[jiht at ict.ac.cn]

On 08:16 Thu 24 Jun     , Kevin Corry wrote:
> On Thursday 24 June 2004 2:01 am, jiht at ict.ac.cn wrote:
> > Hello,
> >
> > I want to block IO coming from filesystem while mapping bh. If the MD is
> > read and written as a file (like dd if=/dev/zero of=/dev/mapper/vd0
> > ...), we can override the ops->read() and ops->write() of the MD
> > (/dev/mapper/vd0), and block the reading and writing properly. But if we
> > make a filesystem on the MD and read/write through the filesystem I do
> > not know how to achieve this.
> >
> > There is a function named __lock_fs() in dm.c in kernel-2.6.6, which calls
> > the function of freeze_bdev() in buffer.c. I have two questions about
> > these functions:
> >
> > 1. If __lock_fs() can block all current reading and writing coming from the
> > filesystem based on the MD which we controlled?
> >
> > 2. If there is any similar function can be called by MD in kernel-2.4.*?
> > How can we block all current reading and writing coming from the filesystem
> > based on the MD? As I know, dm_suspend() in dm.c can defer the IO, but can
> > not block it.
> 
> What exactly are you trying to accomplish by "blocking" I/O? If you're talking 
> about this from the Device-Mapper perspective, we don't care whether the I/O 
> comes from a filesystem or if someone is reading/writing directly to the 
> device. If you want to temporarily suspend I/O, you can simply suspend the DM 
> device. When you resume the device, all the pending I/O will be submitted. 
> But you seem to indicate you want to permanently suspend I/O, which is a 
> horrible idea. All that does is eat up system resources that will never be 
> returned, not to mention that the submitter of the I/Os will have no idea 
> that their I/Os will never complete. If you just want to prevent any more I/O 
> from reaching the physical disks, you can reload the DM device with an 
> "error" or "zero" mapping, which will immediately return all I/O requests, 
> either with an error indicator or a zero-filled buffer.
> 
> Please give us some more details about what your ultimate goal is, and we can 
> try to suggest the proper way to accomplish it using DM.
> 

I don't want to block the I/Os permanently but some unsure long time.  But I 
find when I call suspending function in device-mapper or similar caching I/Os
methods if(->when) the suspending time is long (2-5 seconds) and the I/O 
speed is fast, the memory is eaten up quickly and the kernel is dead.  

My application is like this: there is a DM device which consists of 
"missing targets". When the bhs reach the DM device first, the DM device or
missing targets don't know where these bhs should go and have to ask for the
route information out of kernel. There is a daemon in the user space waiting 
for querying.  The daemon is just a proxy, it asks other host the route 
information , and then informs the DM device or missing targets. These 
operation is time consuming. So what I want is that the process reading or 
writing the DM device can slow down or just pause its work during the querying. 
And then After the missing targets have known its route, the process reading 
or writing the DM device go on its work again. 

Any suggestion is welcome!

Thanks!
Ji Haitao