[lvm-devel] [PATCH 1/6] Pool locking code
Joe Thornber
thornber at redhat.com
Wed Mar 23 14:03:08 UTC 2011
On Tue, 2011-03-22 at 22:21 +0100, Zdenek Kabelac wrote:
> Adding specific functions to lock and unlock pool, to modify
> specific uint64_t*, and to revert all modified uint64_t back.
> +/* prevent modification of pool */
> +int dm_pool_locked(struct dm_pool *p);
> +int dm_pool_lock(struct dm_pool *p, unsigned count)
> + __attribute__((__warn_unused_result__));
> +int dm_pool_unlock(struct dm_pool *p)
> + __attribute__((__warn_unused_result__));
> +int dm_pool_set_uint64(struct dm_pool *p, uint64_t *addr, uint64_t new_value)
> + __attribute__((__warn_unused_result__));
> +int dm_pool_restore(struct dm_pool *p, int check_crc)
> + __attribute__((__warn_unused_result__));
> +
Hi Kabi,
I like what you're trying to do here. But I don't really like the above
interface, particularly the dm_pool_set_uint64() method which is going
to be ugly to use.
Ideally I guess I'd prefer something like:
struct dm_pool_snapshot;
struct dm_pool_snapshot *dm_pool_take_snapshot(struct dm_pool *p);
void dm_pool_destroy_snapshot(struct dm_pool_snapshot *snap);
int dm_pool_compare(struct dm_pool *p, struct dm_pool_snapshot *snap);
int dm_pool_restore_snapshot(struct dm_pool *p, struct dm_pool_snapshot *snap, int release_subsequently_allocated_data);
You'd use the compare function within assertions to check nobody has
changed a pool unexpectedly. There's no concept of a locked pool, you
don't have to change the existing pool code to check if you're locked.
Also you don't need a special interface for changing data within a
locked pool.
The simple way of implementing the above is to just make a copy of the
pool data within the snapshot. Which of course is a very slow op. So
could you give me an idea of the size of a typical pool when you are
locking it? How frequently do you lock?
- Joe
More information about the lvm-devel
mailing list