[dm-devel] Device Mapper Persistent Configuration

[Gili B]

Hi
I didnt receive the email below, so I've copied and pasted it from the archive , sory .
 
Thanks for the reply ..
I have a few followup quesions:
1) If I use a special signature to identify disks, like in mdraid, why must I have a user space tool to discover disks?
If I want all volumes up and ready during a reboot, I prefer that the module do it when it loads.
A user space program will start too late in the boot process.
2)Can you point me to some guide on how to export stuff in proc ?
 
Thanks
-gili
 
 On Sun, Jun 28, 2015 at 8:21 AM, Gili B <gilib123 hotmail com> wrote:

hi
We are starting working on a new device mapper module which has targets similar
to the ones in thin module (pool and thin),  but it adds some additional features.
The user should be able to create and use file systems on the thin volumes.
I wanted to know what is the recommended  way to make the configuration with dmsetup
persistent ?

​You should probably use mdraid as an inspiration.  Put a signature block on every member device.  You can then write a user-space tool to scan devices and find the collections.  Be sure to use a good "signature" for your type of device, plus a good UUID signature so that different generations can be identified.
​ We want that all file systems will be available after reboot.

​If you get the device running early enough, then fstab should be able to mount file systems.
​ Should we write our own configuration tool?  should we add special configuration files?

​You will probably need a user-space tool.  You can probably get away with no configuration file, but you should again use mdraid as inspiration so that your user-space tool gets limits of where to look for member pieces.
​ Should the kernel module we write , automatically discover all the configration and initialize accordingly?
 
 
Regarding debug - Is there a generic way to run dmsetup for example that
prints some inside details on the targets? (for example number of outstanding ios, memory used etc)

​You can do this three ways.  1)  build in IOCTL into your module that can query stuff.  2) export stuff in /sys.  3) export stuff in /proc.  I personally like exporting debug stuff into /proc.  Remember that printk is your friend.  I have even created "command" file in proc that then dump debug information with printk.  If you use /proc, you need to handle multiple instances of your mapper.  I use /proc/{my_project_name}/{instance_name}/...
   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20150629/310140d9/attachment.htm>