All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 01/11] Add mda_slots field for PV info in the cache.
Date: Thu, 25 Nov 2010 14:15:44 +0100	[thread overview]
Message-ID: <4CEE6180.6000706@redhat.com> (raw)
In-Reply-To: <1290115945-27419-2-git-send-email-prajnoha@redhat.com>

Dne 18.11.2010 22:32, Peter Rajnoha napsal(a):
> The code further needs to access the information about metadata areas
> directly quite often without checking the relative position to other
> metadata areas or data areas. IOW, we need to know directly whether
> there is any metadata area at the start of the disk or at the end of the
> disk or any other position we can think of in the future. This way, I
> know exactly which slots are free, which are occupied and I know the
> relative position to other metadata areas without checking any offsets
> etc.
> 
> Using the original list would be quite painful here - either I'd need to
> store the position somewhere or I'll just use this array which seems
> better. Though, the list itself is still there - this is something I'd
> like to discuss... (So I haven't tried to remove the mda_list completely
> yet).
> 
> Signed-off-by: Peter Rajnoha <prajnoha@redhat.com>
> ---
>  lib/cache/lvmcache.c |    1 +
>  lib/cache/lvmcache.h |    2 ++
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/cache/lvmcache.c b/lib/cache/lvmcache.c
> index 60edcec..d1b6dea 100644
> --- a/lib/cache/lvmcache.c
> +++ b/lib/cache/lvmcache.c
> @@ -1357,6 +1357,7 @@ static void _lvmcache_destroy_entry(struct lvmcache_info *info)
>  	_vginfo_detach_info(info);
>  	strcpy(info->dev->pvid, "");
>  	label_destroy(info->label);
> +	dm_free(info->mda_slots);
>  	dm_free(info);
>  }
>  
> diff --git a/lib/cache/lvmcache.h b/lib/cache/lvmcache.h
> index 28f8541..32b4579 100644
> --- a/lib/cache/lvmcache.h
> +++ b/lib/cache/lvmcache.h
> @@ -33,6 +33,7 @@
>  struct cmd_context;
>  struct format_type;
>  struct volume_group;
> +struct metadata_area;


I'm not really sure where we are heading with out  lvmcache.

I'd like to see rather complete removal of this part of code - once we will
start work on thing like Petr's  lvmetad  - which would probably completely
eliminate need of any cache.

I think we should keep our lvmcache as simple as we can only to skip repeated
open & read from device -  everything else should be kept in higher level.
That could make future removal of this code much easier.

I guess we already break this concept in few place - but we should rather fix
those areas instead of add more hardwired functionality into cache level.


Zdenek



  reply	other threads:[~2010-11-25 13:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18 21:32 [PATCH 00/11] Add interface to support adding and removing metadata areas on demand Peter Rajnoha
2010-11-18 21:32 ` [PATCH 01/11] Add mda_slots field for PV info in the cache Peter Rajnoha
2010-11-25 13:15   ` Zdenek Kabelac [this message]
2010-11-25 13:39     ` Peter Rajnoha
2010-11-25 13:45       ` Peter Rajnoha
2010-11-18 21:32 ` [PATCH 02/11] Add pe_start_locked flag in struct physical_volume to retain pe_start Peter Rajnoha
2010-11-18 21:32 ` [PATCH 03/11] Add pv_add_metadata_area to format_handler interface Peter Rajnoha
2010-11-18 21:32 ` [PATCH 04/11] Add pv_remove_metadata_area " Peter Rajnoha
2010-11-25 13:21   ` Zdenek Kabelac
2010-11-18 21:32 ` [PATCH 05/11] Add pv_initialise " Peter Rajnoha
2010-11-25 13:28   ` Zdenek Kabelac
2010-11-18 21:32 ` [PATCH 06/11] Refactor pv_setup to not include the initialisation only code Peter Rajnoha
2010-11-18 21:32 ` [PATCH 07/11] Remove unused _mda_setup Peter Rajnoha
2010-11-18 21:32 ` [PATCH 08/11] Cleanup pv_write to use recent changes in metadata handling interface Peter Rajnoha
2010-11-18 21:32 ` [PATCH 09/11] Remove useless mdas parameter in code creating new PVs Peter Rajnoha
2010-11-18 21:32 ` [PATCH 10/11] Make existing lvmcache_update_pvid public Peter Rajnoha
2010-11-18 21:32 ` [PATCH 11/11] Use new metadata interface to provide better support for PV resize Peter Rajnoha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEE6180.6000706@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=lvm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.