a regular
file to be treated as a block device.
Signed-off-by: Bryn Reeves [EMAIL PROTECTED]
Signed-off-by: Alasdair G Kergon [EMAIL PROTECTED]
---
drivers/md/Kconfig |9
drivers/md/Makefile |1
drivers/md/dm-loop.c | 1036 +++
3 files
On Thu, Jan 10, 2008 at 12:43:19AM +0100, [EMAIL PROTECTED] wrote:
oh, nice to see that this is still alive.
at least i got no crashes and was able to mount and acess more than 300
iso-images with that.
were there fixes/chances since then?
Little has changed for some time - mostly code
On Thu, Aug 30, 2007 at 04:20:35PM -0700, Daniel Phillips wrote:
Resubmitting a bio or submitting a dependent bio from
inside a block driver does not need to be throttled because all
resources required to guarantee completion must have been obtained
_before_ the bio was allowed to proceed
On Mon, Aug 27, 2007 at 11:30:53AM +0100, Al Viro wrote:
3) -ioctl(). What a mess...
Yup.
See also:
Subject: [PATCH] dm: support ioctls on mapped devices: fix with fake file
http://uwsg.indiana.edu/hypermail/linux/kernel/0606.2/2979.html
and related threads.
First of all, we have 3
On Wed, May 30, 2007 at 11:12:37AM +0200, Stefan Bader wrote:
it might be better to indicate -EOPNOTSUPP right from
device-mapper.
Indeed we should. For support, on receipt of a barrier, dm core should
send a zero-length barrier to all active underlying paths, and delay
mapping any further
On Thu, May 31, 2007 at 10:46:04AM +1000, Neil Brown wrote:
What if the truth changes (as can happen with md or dm)?
You get notified in endio() that the barrier had to be emulated?
Alasdair
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the
On Thu, May 31, 2007 at 10:46:04AM +1000, Neil Brown wrote:
If a filesystem cares, it could 'ask' as suggested above.
What would be a good interface for asking?
XFS already tests:
bd_disk-queue-ordered == QUEUE_ORDERED_NONE
Alasdair
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Tue, May 29, 2007 at 11:25:42AM +0200, Stefan Bader wrote:
doing a sort of suspend, issuing the
barrier request, calling flush to all mapped devices and then wait for
in-flight I/O to go to zero?
Something like that is needed for some dm targets to support barriers.
(We needn't always wait
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
The device-mapper position has always been that we require
a zero-length BIO_RW_BARRIER
(i.e. containing no data to read or write - or emulated, possibly
