Re: [RFC PATCH] dm: allow a dm-fs-style device to be shared via dm-ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mike,

On Thu, May 13, 2010 at 10:53 PM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
> Hi Will,
>
> On Thu, May 13 2010 at  9:39pm -0400,
> Will Drewry <wad@xxxxxxxxxxxx> wrote:
>
>> Following on the discussion of booting directly to a device-mapper
>> device, two things were made clear:
>> 1. The ioctl interface's name and uuid are mandatory for udev to work
>> 2. There is a functional gap between the dm(-fs) and dm-ioctl
>>
>> This change adds one function which is used for binding a given mapped
>> device to a name+uuid in the dm-ioctl hash table.  In addition, it
>> ensures that public functions are available that allow mapped devices
>> and tables to be created and associated with shared code paths in
>> dm-ioctl:
>> - suspend flags and block integrity registration are now exposed
>> - dm_table_complete() now prepares a table for use completely
>>   (builds the btree; sets the type; allocates md pools)
>
> I have done a preliminary review and have some comments inlined below.

Thanks for the review and comments!

>> Ideally, this lays the groundwork for any kernel code to create fully
>> functional mapped devices, but I'd appreciate feedback on if this
>> approach makes sense/is safe, preferred function names, and if it
>> integrates with the current direction.
>>
>> (I can also pair this with the init code patch if it makes sense to show
>> consumer code.)
>
> It would certainly help follow-on reviews as we take a closer look.  For
> the next version of your work I'd recommend sharing all related code in
> a series (e.g.: core DM patch 1/2, init patch 2/2).

Will do - just finishing up integrating comments from Alasdair and wanted
to see if the direction for core DM changes would be reasonable.


>> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
>> index 9924ea2..66726d1 100644
>> --- a/drivers/md/dm-table.c
>> +++ b/drivers/md/dm-table.c
>> @@ -900,7 +900,7 @@ static int setup_indexes(struct dm_table *t)
>>  /*
>>   * Builds the btree to index the map.
>>   */
>> -int dm_table_complete(struct dm_table *t)
>> +int dm_table_build_index(struct dm_table *t)
>>  {
>>       int r = 0;
>>       unsigned int leaf_nodes;
>> @@ -919,6 +919,48 @@ int dm_table_complete(struct dm_table *t)
>>       return r;
>>  }
>>
>> +
>> +/*
>> + * Prepares the table for use by building the indices,
>> + * setting the type, and allocating mempools.
>> + */
>> +int dm_table_complete(struct dm_table *t)
>> +{
>> +     int r = 0;
>> +
>> +     r = dm_table_build_index(t);
>> +     if (r) {
>> +             DMWARN("unable to build btrees");
>> +             return r;
>> +     }
>> +     r = dm_table_set_type(t);
>> +     if (r) {
>> +             DMWARN("unable to set table type");
>> +             return r;
>> +     }
>> +     r = dm_table_alloc_md_mempools(t);
>> +     if (r)
>> +             DMWARN("unable to allocate mempools");
>> +
>> +     return r;
>> +}
>
> Please have dm_table_set_type() come before dm_table_build_index() to
> preserve the existing call sequence.  It is better to check the type
> related constraints before going on to build the indices.

Nice catch! I had meant to preserve the order.

>> +
>> +/*
>> + * Register the mapped device for blk_integrity support if
>> + * the underlying devices support it.
>> + */
>> +int dm_table_prealloc_integrity(struct dm_table *t, struct mapped_device *md)
>> +{
>> +     struct list_head *devices = dm_table_get_devices(t);
>> +     struct dm_dev_internal *dd;
>> +
>> +     list_for_each_entry(dd, devices, list)
>> +             if (bdev_get_integrity(dd->dm_dev.bdev))
>> +                     return blk_integrity_register(dm_disk(md), NULL);
>> +
>> +     return 0;
>> +}
>
> I think we need more justification for why you'd want to expose
> dm_table_prealloc_integrity() as a public interface.  Makes DM a bit
> more brittle with unknown gain at the moment.  Why not just move the
> dm_table_prealloc_integrity() call to dm_table_complete() -- just before
> dm_table_alloc_md_mempools()?

For some reason I special cased it, but I have no idea why. I'll fold it in
to dm_table_complete().

>
>>  static DEFINE_MUTEX(_event_lock);
>>  void dm_table_event_callback(struct dm_table *t,
>>                            void (*fn)(void *), void *context)
>> diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
>> index 1381cd9..95fea4c 100644
>> --- a/include/linux/device-mapper.h
>> +++ b/include/linux/device-mapper.h
>> @@ -215,6 +215,18 @@ void dm_set_mdptr(struct mapped_device *md, void *ptr);
>>  void *dm_get_mdptr(struct mapped_device *md);
>>
>>  /*
>> + * Export the device via the ioctl interface
>> + */
>> +int dm_ioctl_export(struct mapped_device *md, const char *name,
>> +                 const char *uuid);
>> +
>> +/*
>> + * Suspend feature flags
>> + */
>> +#define DM_SUSPEND_LOCKFS_FLAG               (1 << 0)
>> +#define DM_SUSPEND_NOFLUSH_FLAG              (1 << 1)
>
> You're missing the matching removal of these flags from drivers/md/dm.h

I'll pull that into the next mail as well once I get the init changes in better
shape.

Thanks again!
will

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel


[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux