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

[Kevin Corry]

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.

-- 
Kevin Corry
kevcorry at us.ibm.com
http://evms.sourceforge.net/