<div dir="ltr"><div>Hi, folks:</div><div><br></div><div>Sorry for the insufficient information about my question last week.</div><div><br></div><div>This is my environment for the test.</div><div> Kernel version : 3.12.0-rc7+</div>
<div> LVM version : 2.02.103</div><div><br></div><div>I had currently done some test with the dm-thin targets.</div><div>Here is my simple script to create a pool with 32MB metadata, and a volumn on it.</div><div><br></div>
<div>$ sudo vgcreate vg /dev/sda1</div><div>$ sudo lvcreate --type thin-pool --thinpool tpool vg --size 800G --poolmetadatasize 32M --alloc anywhere -c 64k</div><div>$ sudo lvcreate --name lv vg --virtualsize 800G --type thin --thinpool tpool</div>
<div><br></div><div>After formating, mounting, and some I/O test, the pool and volumn work well.</div><div>Then I try to expand the metadata device to 64M with the following command</div><div><br></div><div>$ sudo lvresize --poolmetadata +32M vg/tpool</div>
<div><br></div><div>But I got error message on the terminal</div><div> Extending logical volume tpool_tmeta to 64.00 MiB.</div><div> device-mapper: resume ioctl on failed: No space left on device</div><div> Unable to resume vg-tpool-tpoolool (253:3)</div>
<div> Problem reactivating tpool</div><div> libdevmapper exiting with 2 device(s) still suspended.</div><div><br></div><div>The mounted volumn seems not being accessible because of being suspended.</div><div>It can only works normally from being suspended until I execute the following command.</div>
<div>$ sudo lvresize --size -32M /dev/mapper/vg-tpool_tmeta</div><div><br></div><div>I try to find out the reason why -ENOSPC happens. Here is function sm_ll_extend().</div><div><br></div><div>static int sm_metadata_extend(struct dm_space_map *sm, dm_block_t extra_blocks)</div>
<div>{</div><div><span class="" style="white-space:pre"> </span>...</div><div><span class="" style="white-space:pre"> </span>dm_block_t old_len = smm->ll.nr_blocks;</div><div><br></div><div><span class="" style="white-space:pre"> </span>smm->begin = old_len;<span class="" style="white-space:pre"> </span>// So smm->begin = smm->ll.nr_blocks here</div>
<div><span class="" style="white-space:pre"> </span>memcpy(&smm->sm, &bootstrap_ops, sizeof(smm->sm));</div><div><br></div><div><span class="" style="white-space:pre"> </span>/*</div><div><span class="" style="white-space:pre"> </span> * Extend.</div>
<div><span class="" style="white-space:pre"> </span> */</div><div><span class="" style="white-space:pre"> </span>r = sm_ll_extend(&smm->ll, extra_blocks);</div><div><span class="" style="white-space:pre"> </span></div>
<div><span class="" style="white-space:pre"> </span>/*</div><div><span class="" style="white-space:pre"> </span> * Switch back to normal behaviour.</div><div><span class="" style="white-space:pre"> </span> */</div><div><span class="" style="white-space:pre"> </span>memcpy(&smm->sm, &ops, sizeof(smm->sm));</div>
<div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>for (i = old_len; !r && i < smm->begin; i++)</div><div><span class="" style="white-space:pre"> </span>r = sm_ll_inc(&smm->ll, i, &ev);</div>
<div><br></div><div><span class="" style="white-space:pre"> </span>...</div><div>}</div><div><br></div><div>In this function, smm->begin is set as smm->ll.nr_blocks.</div><div>Space-map operations are replaced with another set of dm_space_map operations, bootstrap_ops, in order to flick into a mode, where all blocks get allocated in the new area.</div>
<div>Just like what it did in function dm_sm_metadata_create().</div><div><br></div><div>After these steps, the ops will be replaced again with the original dm_space_map structure. </div><div><br></div><div>In function sm_ll_extend(), there is a forloop used to incrementally extend the nr_blocks. </div>
<div>dm_tm_new_block() is called in each loop, here is the call tree of dm_tm_new_block():</div><div><br></div><div> dm_tm_new_block()</div><div> -> dm_sm_new_block()</div><div> -> sm_bootstrap_new_block()</div>
<div><br></div><div>In function sm_bootstrap_new_block()</div><div> ...</div><div><span class="" style="white-space:pre"> </span>/*</div><div><span class="" style="white-space:pre"> </span> * We know the entire device is unused.</div>
<div><span class="" style="white-space:pre"> </span> */</div><div><span class="" style="white-space:pre"> </span>if (smm->begin == smm->ll.nr_blocks)</div><div><span class="" style="white-space:pre"> </span>return -ENOSPC;</div>
<div><br></div><div>Because the smm->begin is set as smm->ll.nr_blocks in function sm_ll_extend(), sm_bootstrap_new_block() will always returns -ENOSPC here.</div><div>It seems like the reason why I get -ENOSPC error and cannot successfully resize the metadata size.</div>
<div>The smm->ll.nr_blocks is updated after the for loop.</div><div><br></div><div>By the way, it will be success if I try to extend the metedata size with smaller size, such as</div><div>$ sudo lvresize --poolmetadata +4M vg/tpool</div>
<div>$ sudo lvresize --poolmetadata +8M vg/tpool</div><div>$ sudo lvresize --poolmetadata +12M vg/tpool</div><div><br></div><div>This is because old nr_blocks and new nr_blocks(say, old block number plus extra_blocks) are the same after the calculation of dm_sector_div_up(), the for loop in sm_ll_extend() will not being executed when nr_blocks is the same.</div>
<div><br></div><div>Compare with steps when dm_sm_metadata_create(), the smm->begin is set as (superblock + 1),and the ll.nr_blocks is set as 0 in function sm_ll_new_metadata(). So -ENOSPC will not be returned when creating a new pool.</div>
<div><br></div><div>So this is my question, is the following statements in sm_bootstrap_new_block() needed? Or do I misunderstanding something in the procedure of extending pool metadata?</div><div><br></div><div><span class="" style="white-space:pre"> </span>/*</div>
<div><span class="" style="white-space:pre"> </span> * We know the entire device is unused.</div><div><span class="" style="white-space:pre"> </span> */</div><div><span class="" style="white-space:pre"> </span>if (smm->begin == smm->ll.nr_blocks)</div>
<div><span class="" style="white-space:pre"> </span>return -ENOSPC;</div><div><br></div><div>Any help would be grateful. Thanks.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/30 Wun-Yen Liang <span dir="ltr"><<a href="mailto:burton.paramountcy@gmail.com" target="_blank">burton.paramountcy@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi, folks,</div><div><br></div><div>I noticed that the dm-thin metadata can be resized since LVM tools v2.02.99, and the related code in kernel had been added since 3.10, say,</div>
<div>maybe_resize_metadata_dev() in pool_resume in dm-thin.c.</div>
<div><br></div><div>I'm currently doing some experiments with dm-thin targets, with linux-3.11¡BLVM2.2.02.103</div><div>Here is my script to create thin-pool and thin-volumn on my device, a 200GB pool with 32M metadata</div>
<div> $ sudo vgcreate vg /dev/sda1</div><div> $ sudo lvcreate --type thin-pool --thinpool tpool vg --size 200G --poolmetadatasize 32M -c 1M</div><div> $ sudo lvcreate --name lv vg --virtualsize 100G --type thin --thinpool tpool</div>
<div><br></div><div>Then, I try to increase the metadata size with the following command,</div><div> $ sudo lvresize --poolmetadata +4M vg/tpool</div><div> Extending logical volume tp_tmeta to 36.00 MiB.</div><div>
Logical volume tpool successfully resized</div><div><br></div><div>by executing "dmsetup status"/ "dmsetup table" command, the length of the *_tmeta volumn is successfully expended with 4MB size.</div>
<div><br></div><div>But when trying to resize the metadata lv to 64MB</div><div> $ sudo lvresize --poolmetadata +28M vg/tpool</div><div> Extending logical volume tpool_tmeta to 64.00 MiB.</div><div> device-mapper: resume ioctl on failed: No space left on device</div>
<div> Unable to resume vg-tpool-tpool (253:3)</div><div> Problem reactivating tpool</div><div> libdevmapper exiting with 2 device(s) still suspended.</div><div><br></div><div>I get error message in this step.</div>
<div>By executing vgs/lvs command, I still have free space in my volumn group and pool.</div><div>The dm table of *_tmeta device seems had been modified, but resumed fail.</div><div><br></div><div>The same kind of error also happens when I try to expend the metadata device with a big size, like 1GB.</div>
<div>After tracing the code, the -ENOSPC seems being returned from sm_bootstrap_new_block() in dm-space-map-metadata.c. </div><div><br></div><div>Here is my questions.</div><div>Did I miss some steps before resizing the metadata device?</div>
<div>Or, did the resizing of dm-thin metadata is limitted? If yes, what is the limitation?</div><div><br></div><div>Any help would be grateful. Thanks</div><div><br></div><div>Burton</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<div>Q€ò</div>
</div>