Question about dm target size

Question about dm target size

[Josef Bacik]

Hello,

I'm creating a dm target to better test power fail situations and I'm 
having trouble figuring out how to make the dm device appear as a 
different size.  So for example you do the normal dm table

offset size power-fail /dev/whatever args

I want to use the entire size of /dev/whatever, but I want my dm device 
to show up as size/2.  So right now I'm doing this in my ->ctr function

ti->len /= 2;

Is that acceptable, or will this have some side-effect that's going to 
bite me in the ass?  I can't see any other target that does something 
similar and there appears to be no helper function.  This seems to work 
as far as blockdev --getsz is concerned, but I'm worried I need to do 
more.  Thanks,

Josef

Re: Question about dm target size

[Mike Snitzer]

On Tue, Nov 11 2014 at  7:37pm -0500,
Josef Bacik <jbacik@fb.com> wrote:

> Hello,
> 
> I'm creating a dm target to better test power fail situations and
> I'm having trouble figuring out how to make the dm device appear as
> a different size.  So for example you do the normal dm table
> 
> offset size power-fail /dev/whatever args

So "size" should be constrained to:
size=$(sudo blockdev --getsz /dev/whatever); $((size/2))

> I want to use the entire size of /dev/whatever, but I want my dm
> device to show up as size/2.  So right now I'm doing this in my
> ->ctr function
> 
> ti->len /= 2;

You don't want to mess with ti->len.  If you have "size" be size/2
then ti->len will automatically reflect that.

But anyway, I'm mot really following how you'd map the entire
/dev/whatever but only expose half its size to the user.  What would the
target's ->map function be doing?
 
> Is that acceptable, or will this have some side-effect that's going
> to bite me in the ass?  I can't see any other target that does
> something similar and there appears to be no helper function.  This
> seems to work as far as blockdev --getsz is concerned, but I'm
> worried I need to do more.  Thanks,

dm-thinp is all about establishing thin volumes of fictional size...
wondering what kind of helper you were hoping to find.

The target's ->ctr would open /dev/whatever and internalize
/dev/whatever's size and ->map would deal with remapping of bios sent to
the target over to /dev/whatever.

Re: Question about dm target size

[Josef Bacik]

Sorry for top posting, my phone client doesn't do inline.

I'm splitting the disk in half, writing to alternating sides of the disk and keeping track of where which block is so when the power fail event occurs the subsequent reads come from the corresponding mirror in the disk. The disk needs to appear to be size/2 for the mkfs to know the correct size, but my target needs to be able to write up to size.  I looked at thinp but it reflects the full size right? It's just like a sparse find correct? My ->map function does the right thing, doing the ->len trick makes it all work out right, but this is really isolated testing. Thanks,

Josef

Mike Snitzer <snitzer@redhat.com> wrote:


On Tue, Nov 11 2014 at  7:37pm -0500,
Josef Bacik <jbacik@fb.com> wrote:

> Hello,
>
> I'm creating a dm target to better test power fail situations and
> I'm having trouble figuring out how to make the dm device appear as
> a different size.  So for example you do the normal dm table
>
> offset size power-fail /dev/whatever args

So "size" should be constrained to:
size=$(sudo blockdev --getsz /dev/whatever); $((size/2))

> I want to use the entire size of /dev/whatever, but I want my dm
> device to show up as size/2.  So right now I'm doing this in my
> ->ctr function
>
> ti->len /= 2;

You don't want to mess with ti->len.  If you have "size" be size/2
then ti->len will automatically reflect that.

But anyway, I'm mot really following how you'd map the entire
/dev/whatever but only expose half its size to the user.  What would the
target's ->map function be doing?

> Is that acceptable, or will this have some side-effect that's going
> to bite me in the ass?  I can't see any other target that does
> something similar and there appears to be no helper function.  This
> seems to work as far as blockdev --getsz is concerned, but I'm
> worried I need to do more.  Thanks,

dm-thinp is all about establishing thin volumes of fictional size...
wondering what kind of helper you were hoping to find.

The target's ->ctr would open /dev/whatever and internalize
/dev/whatever's size and ->map would deal with remapping of bios sent to
the target over to /dev/whatever.

Re: Question about dm target size

[Zdenek Kabelac]

Dne 12.11.2014 v 03:30 Josef Bacik napsal(a):
> Sorry for top posting, my phone client doesn't do inline.
>
> I'm splitting the disk in half, writing to alternating sides of the disk and keeping track of where which block is so when the power fail event occurs the subsequent reads come from the corresponding mirror in the disk. The disk needs to appear to be size/2 for the mkfs to know the correct size, but my target needs to be able to write up to size.  I looked at thinp but it reflects the full size right? It's just like a sparse find correct? My ->map function does the right thing, doing the ->len trick makes it all work out right, but this is really isolated testing. Thanks,
>

Just a side note - maybe you would like to rather extend functionality of 
dm-flakey  target ?

Zdenek



> Josef
>
> Mike Snitzer <snitzer@redhat.com> wrote:
>
>
> On Tue, Nov 11 2014 at  7:37pm -0500,
> Josef Bacik <jbacik@fb.com> wrote:
>
>> Hello,
>>
>> I'm creating a dm target to better test power fail situations and
>> I'm having trouble figuring out how to make the dm device appear as
>> a different size.  So for example you do the normal dm table
>>
>> offset size power-fail /dev/whatever args
>
> So "size" should be constrained to:
> size=$(sudo blockdev --getsz /dev/whatever); $((size/2))
>
>> I want to use the entire size of /dev/whatever, but I want my dm
>> device to show up as size/2.  So right now I'm doing this in my
>> ->ctr function
>>
>> ti->len /= 2;
>
> You don't want to mess with ti->len.  If you have "size" be size/2
> then ti->len will automatically reflect that.
>
> But anyway, I'm mot really following how you'd map the entire
> /dev/whatever but only expose half its size to the user.  What would the
> target's ->map function be doing?
>
>> Is that acceptable, or will this have some side-effect that's going
>> to bite me in the ass?  I can't see any other target that does
>> something similar and there appears to be no helper function.  This
>> seems to work as far as blockdev --getsz is concerned, but I'm
>> worried I need to do more.  Thanks,
>
> dm-thinp is all about establishing thin volumes of fictional size...
> wondering what kind of helper you were hoping to find.
>
> The target's ->ctr would open /dev/whatever and internalize
> /dev/whatever's size and ->map would deal with remapping of bios sent to
> the target over to /dev/whatever.
>

Re: Question about dm target size

[Josef Bacik]

On 11/12/2014 03:45 AM, Zdenek Kabelac wrote:
> Dne 12.11.2014 v 03:30 Josef Bacik napsal(a):
>> Sorry for top posting, my phone client doesn't do inline.
>>
>> I'm splitting the disk in half, writing to alternating sides of the
>> disk and keeping track of where which block is so when the power fail
>> event occurs the subsequent reads come from the corresponding mirror
>> in the disk. The disk needs to appear to be size/2 for the mkfs to
>> know the correct size, but my target needs to be able to write up to
>> size.  I looked at thinp but it reflects the full size right? It's
>> just like a sparse find correct? My ->map function does the right
>> thing, doing the ->len trick makes it all work out right, but this is
>> really isolated testing. Thanks,
>>
>
> Just a side note - maybe you would like to rather extend functionality
> of dm-flakey  target ?
>

I did that first but it ended up being really ugly.  With all the 
varying functionality in dm-flakey it ended up making the table format 
horrible and the code a spaghetti of if (test_bit()) crap everywhere. 
Thanks,

Josef

Re: Question about dm target size

[Zdenek Kabelac]

Dne 12.11.2014 v 12:00 Josef Bacik napsal(a):
> On 11/12/2014 03:45 AM, Zdenek Kabelac wrote:
>> Dne 12.11.2014 v 03:30 Josef Bacik napsal(a):
>>> Sorry for top posting, my phone client doesn't do inline.
>>>
>>> I'm splitting the disk in half, writing to alternating sides of the
>>> disk and keeping track of where which block is so when the power fail
>>> event occurs the subsequent reads come from the corresponding mirror
>>> in the disk. The disk needs to appear to be size/2 for the mkfs to
>>> know the correct size, but my target needs to be able to write up to
>>> size.  I looked at thinp but it reflects the full size right? It's
>>> just like a sparse find correct? My ->map function does the right
>>> thing, doing the ->len trick makes it all work out right, but this is
>>> really isolated testing. Thanks,
>>>
>>
>> Just a side note - maybe you would like to rather extend functionality
>> of dm-flakey  target ?
>>
>
> I did that first but it ended up being really ugly.  With all the varying
> functionality in dm-flakey it ended up making the table format horrible and
> the code a spaghetti of if (test_bit()) crap everywhere. Thanks,
>


The other thing that lvm2 test suite is using is -

we take a base 'linear' device mapped on some origin - and we create a 
segmented device where individual segment are either mapper to 'original' 
device or to a 'zero' origin or  'error' origin depending on
whether you want to read  0 or 'err' from a device.

Example of such mapping 'trick':

normal mapping for device pv1:

pv1: 0 69120 linear 7:2 0


mapping with single error segment sector of device pv1:

pv1: 0 2050 linear 7:2 0
pv1: 2050 1 error
pv1: 2051 67069 linear 7:2 2051

You could reload table mapping for pv1 any-time with suspend/resume.


Zdenek

Re: Question about dm target size

[Heinz Mauelshagen]

On 11/12/2014 01:37 AM, Josef Bacik wrote:
> Hello,
>
> I'm creating a dm target to better test power fail situations and I'm 
> having trouble figuring out how to make the dm device appear as a 
> different size.  So for example you do the normal dm table
>
> offset size power-fail /dev/whatever args
>
> I want to use the entire size of /dev/whatever, but I want my dm 
> device to show up as size/2.  So right now I'm doing this in my ->ctr 
> function
>
> ti->len /= 2;

Passing in "ti->len = 'size of your dev in sectors' / 2" is what you want.

Heinz

>
> Is that acceptable, or will this have some side-effect that's going to 
> bite me in the ass?  I can't see any other target that does something 
> similar and there appears to be no helper function.  This seems to 
> work as far as blockdev --getsz is concerned, but I'm worried I need 
> to do more.  Thanks,
>
> Josef
>
> -- 
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: Question about dm target size

[Bryn M. Reeves]

On Tue, Nov 11, 2014 at 07:37:44PM -0500, Josef Bacik wrote:
> Hello,
> 
> I'm creating a dm target to better test power fail situations and I'm having
> trouble figuring out how to make the dm device appear as a different size.
> So for example you do the normal dm table
> 
> offset size power-fail /dev/whatever args

Just make the size argument in your table be equal to dev_size / 2. This is
where ti->len comes from and it's the correct way to tell device-mapper how
big your mapped device should be.

Your ctr can then parse out /dev/whatever from its args, open it and do
whatever it likes with it. Access to that device by your target code is in
no way constrained by the offset/size params used in the table.

E.g.:

# dmsetup create pf0 --table="0 2048 power-fail /dev/whatever foo bar"

Would create a 1M device named pf0. The power-fail target could still access
the whole of /dev/whatever if it wants to.

within the 
Regards,
Bryn.