On Tue, Jan 08 2019 at 2:52pm -0500,
Bryan Gurney <bgurney@xxxxxxxxxx> wrote:
> On Tue, Jan 8, 2019 at 11:23 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
> >
> > I'm fine with it as is, but I have a different concern: why does this
> > target need to override the queue_limits at all? What is the benefit to
> > rigidly imposing the provided 512 or 4096 bytes for all of
> > {logical_block,physical_block,minimum_io,optimal_io}_size?
> >
>
> This is a bit of a complex question, which may cover multiple areas.
> I unfortunately don't have as much expertise in the "backend" of the
> original test target code at the heart of dm-dust; I'm still learning
> it as I go.
>
> On the "frontend": The "bad block list" has a "grain size" of the
> block size of the device (therefore, "block 1" of a 4096-byte block
> device starts at byte offset 4096, while "block 1" of a 512-byte block
> device starts at byte offset 512.)
>
> There is definitely value in dm-dust emulating a 4K native device, as
> it will help to reproduce bugs. In the absence of a real device that
> is 4K native, it can be created on top of a 512-byte logical block
> size device to create a "512-byte write detector", of sorts.
>
> (An early version of dm-dust was actually a reproducer for the commit
> "isofs: reject hardware sector size > 2048 bytes".)
>
> > If the underlying device is a 4K native device it simply cannot handle
> > 512b IO. At a minimum you need to verify that the underlying device can
> > even handle 512b IO.
> >
>
> This specific case is a bug, and I want to fix it. (During earlier
> testing, I was wondering why it was possible to set up a 512-byte
> dm-dust device on top of a 4K native device.)
>
> I need to add a check in the "dmsetup create" process, to verify if
> the underlying device's logical_block_size is small enough to handle
> the minimum I/O size.
Would prefer to see this target accept any "block size" and _not_ use
that size for the queue_limits. Quite a few DM targets provide such
arbitrary addressing (e.g. dm-stripe, dm-thin, dm-cache).
You'd then just verify that the user provided "block size" isn't smaller
than logical_block_size.
Any novelty of allowing the user to specify 512b vs 4K for the block
size could easily be provided by something basic like scsi_debug as the
underlying device.
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
