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@xxxxxxxxxx> wrote: On Tue, Nov 11 2014 at 7:37pm -0500, Josef Bacik <jbacik@xxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
