Re: Device Mapper Persistent Configuration

Re: Device Mapper Persistent Configuration

[Gili B]

[-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --]

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}/...
   		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 4702 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Device Mapper Persistent Configuration

[Doug Dumitru]

[-- Attachment #1.1: Type: text/plain, Size: 6943 bytes --]

Gili,

For some reason, reply-all did not pick up your email address.  My mistake.

1)  This is usually done from user space.  User space programs can run
really early.  mdadm does this to start software raid sets.  It is probably
possible to scan devices from the module, but a lot of stuff may not be
there yet if you statically load it.  device-mapper block devices are
allowed to "stack", so one of your constituent devices could be /dev/md0,
or crypt target, or a network mount, or who knows.

In terms of "how early" your user space program can run, the answer is that
it can run from initrd before the root file system is even mounted
read/write.

2)  Creating stuff in proc has a number of articles on-line.  I don't have
a link handy right now.  One thing to watch out for is that the proc
interface changed pretty radically in 3.10.0.  Before this, files uses a
simple buffer API.  After this, file use the stock system sequential file
API.  The buffer API had an edge condition deadlock, thus the change.

The "pieces" are proc_mkdir(...) to create a directory (pretty simple), and
here are helper functions from some of my code to create and delete an
actual proc "file".  Note that this code does not use function prototypes,
so RdFn and WtFn should actually be prototyped as:

int ProcRead_vars_stream(struct seq_file *m, void *dev, void *pv)

I use "dev" as a pointer to the "device context" that device mapper uses to
track instances.  Device context is actually a windows driver term for
block filters, which are the analog of a device mapper block filter.  "pv"
is a pointer to more local data.  This can let you write a single proc
handler function, but give it multiple tasks based on the data parameter.

This code is from a really big and convoluted module, so I can't give you
much more of it.


void * _shim_create_proc_seq_entry(char *name, void *parent, int mode, void
*RdFn, void *WtFn, void *dev, void *data, u64 MaxIdx)

{
    struct _PROC_RES *r;

    if ( !( r = kzalloc(sizeof(*r), GFP_KERNEL) ) ) return NULL;

    r->file_ops.owner    = THIS_MODULE;

    strcpy(r->name, name);
    r->mode       = mode;
    r->RdFn       = RdFn;
    r->ShowFn     = RdFn;
    r->WtFn       = WtFn;
    r->dev        = dev;
    r->data       = data;
    r->ProcParent = parent;
    r->MaxIdx     = MaxIdx;

    switch ( mode ) {
        case 0 :            // Read only - single access
            r->file_ops.open    = _shim_proc_open;
            r->file_ops.read    = seq_read;
            r->file_ops.llseek  = seq_lseek;
            r->file_ops.release = single_release;
            r->ProcHandle = proc_create_data(r->name, 0, parent,
&r->file_ops, r);
            break;
        case 1 :            // Read only - multiple access
            r->file_ops.open    = _shim_proc_open_mul;
            r->file_ops.read    = seq_read;
            r->file_ops.llseek  = seq_lseek;
            r->file_ops.release = seq_release;

            r->seq_ops.start = _shim_proc_seq_start;
            r->seq_ops.next  = _shim_proc_seq_next;
            r->seq_ops.stop  = _shim_proc_seq_stop;
            r->seq_ops.show  = _shim_proc_seq_show;

            r->ProcHandle = proc_create_data(r->name, 0, parent,
&r->file_ops, r);
            break;
        case 2 :            // Write only
            BUG();
            break;
        case 3 :            // Read write - single access
            r->file_ops.open    = _shim_proc_open;
            r->file_ops.read    = seq_read;
            r->file_ops.write   = _shim_proc_seq_write;
            r->file_ops.llseek  = seq_lseek;
            r->file_ops.release = single_release;
            r->ProcHandle = proc_create_data(r->name, 0644, parent,
&r->file_ops, r);
            break;
    }

    return r;
}

void _shim_remove_proc_seq_entry(void *data)

{
    struct _PROC_RES    *r = data;

    remove_proc_entry(r->name, r->ProcParent);
    kfree(r);
}


On Sun, Jun 28, 2015 at 11:42 PM, Gili B <gilib123@hotmail.com> wrote:

> 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}/...
>
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>



-- 
Doug Dumitru
EasyCo LLC

[-- Attachment #1.2: Type: text/html, Size: 11104 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Device Mapper Persistent Configuration

[Doug Dumitru]

[-- Attachment #1.1: Type: text/plain, Size: 2232 bytes --]

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}/...
​


>
>
> Thanks
> -gili
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>



-- 
Doug Dumitru
EasyCo LLC

[-- Attachment #1.2: Type: text/html, Size: 4018 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Device Mapper Persistent Configuration

[Gili B]

[-- Attachment #1.1: Type: text/plain, Size: 821 bytes --]

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 ?
We want that all file systems will be available after reboot.
Should we write our own configuration tool?  should we add special configuration files?
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)
 
 
Thanks
-gili
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1122 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]