All of lore.kernel.org
 help / color / mirror / Atom feed
* are there usage examples for dm_sm_metadata_{create|open}?
@ 2014-05-03  2:24 John Utz
  2014-05-06 13:17 ` Joe Thornber
  0 siblings, 1 reply; 3+ messages in thread
From: John Utz @ 2014-05-03  2:24 UTC (permalink / raw)
  To: dm-devel@redhat.com

Hi;

I am developing a simulator for ZBC/ZAC devices using the linear target source code as the starting point. I talked briefly with Ric Wheeler about this project at Napa so he may be in a position to provide you with more context than i am putting into this email.

Since this simulator is expected to be highly configurable i dont have the luxury of hardcoding anything important, so i am on the hunt for A Cunning Plan.

Specifically, I need to be able to configure the number and size of a series of equally sized subdivisions the linear space into discrete equally sized chunks and then *save* this information off somewhere for future use so that we know how to interpret the data that has been saved to the underlying device.

The needs for the simulator metadata are pretty simple; number of subdivisions, size of subdivisions, etc. They just need to persist beyond the lifetime of the module.

So, the stuff in persistent-data sure seems like a good candidate for getting the job done. :-)

It seems like the first basic action one would want to perform would be to create a metadata 'blob' and then at some point in the future one would regularly want to open said metadata blob. The dm_sm_metadata_create and open functions seem perfect for the job.

But for some reason, I am unable to find a place in the md directory where this is getting used.

I would have thought that dm-cache-metadata.c would be using it, but it doesnt seem to be thinking about this in the same way. It uses dm_block_manager_create() and __create_persistent_data_objects().

I have perused dm-cache-metadata.c and dm-thin-metadata.c and they seem significantly more ambitious than anything the simulator needs to do.

Can any of you folks provide me with some guidance or sample code to look at to get me bootstrapped toward getting this done?

tnx!

johnu

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: are there usage examples for dm_sm_metadata_{create|open}?
  2014-05-03  2:24 are there usage examples for dm_sm_metadata_{create|open}? John Utz
@ 2014-05-06 13:17 ` Joe Thornber
  2014-05-06 15:59   ` John Utz
  0 siblings, 1 reply; 3+ messages in thread
From: Joe Thornber @ 2014-05-06 13:17 UTC (permalink / raw)
  To: device-mapper development

HI John,

On Sat, May 03, 2014 at 02:24:48AM +0000, John Utz wrote:
> So, the stuff in persistent-data sure seems like a good candidate for getting the job done. :-)

It's nice that you're considering using the pd library.  Probably the
simplest user of pd is the dm-era target.

> It seems like the first basic action one would want to perform would
> be to create a metadata 'blob' and then at some point in the future
> one would regularly want to open said metadata blob. The
> dm_sm_metadata_create and open functions seem perfect for the job.
> But for some reason, I am unable to find a place in the md directory
> where this is getting used.

Use dm_tm_create_with_sm(), this creates both the transaction manager,
which you *must* have, and the metadata space map.  See the comment at
the end of drivers/md/persistent-data/dm-transaction-manager.h

> I would have thought that dm-cache-metadata.c would be using it, but
  it doesnt seem to be thinking about this in the same way. It uses
  dm_block_manager_create() and __create_persistent_data_objects().

It does, indirectly.

- Joe

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: are there usage examples for dm_sm_metadata_{create|open}?
  2014-05-06 13:17 ` Joe Thornber
@ 2014-05-06 15:59   ` John Utz
  0 siblings, 0 replies; 3+ messages in thread
From: John Utz @ 2014-05-06 15:59 UTC (permalink / raw)
  To: device-mapper development

Sweet! I am gonna jump right on studying dm-era today and will get back to you guys with any Q.

tnx so much for you help Joe!

johnu
________________________________________
From: dm-devel-bounces@redhat.com [dm-devel-bounces@redhat.com] on behalf of Joe Thornber [thornber@redhat.com]
Sent: Tuesday, May 06, 2014 6:17 AM
To: device-mapper development
Subject: Re: [dm-devel] are there usage examples for dm_sm_metadata_{create|open}?

HI John,

On Sat, May 03, 2014 at 02:24:48AM +0000, John Utz wrote:
> So, the stuff in persistent-data sure seems like a good candidate for getting the job done. :-)

It's nice that you're considering using the pd library.  Probably the
simplest user of pd is the dm-era target.

> It seems like the first basic action one would want to perform would
> be to create a metadata 'blob' and then at some point in the future
> one would regularly want to open said metadata blob. The
> dm_sm_metadata_create and open functions seem perfect for the job.
> But for some reason, I am unable to find a place in the md directory
> where this is getting used.

Use dm_tm_create_with_sm(), this creates both the transaction manager,
which you *must* have, and the metadata space map.  See the comment at
the end of drivers/md/persistent-data/dm-transaction-manager.h

> I would have thought that dm-cache-metadata.c would be using it, but
  it doesnt seem to be thinking about this in the same way. It uses
  dm_block_manager_create() and __create_persistent_data_objects().

It does, indirectly.

- Joe

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-05-06 15:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-03  2:24 are there usage examples for dm_sm_metadata_{create|open}? John Utz
2014-05-06 13:17 ` Joe Thornber
2014-05-06 15:59   ` John Utz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.