All of lore.kernel.org
 help / color / mirror / Atom feed
* [linux-lvm] Tool for defragmentation of extends?
@ 2010-11-29 22:37 Andrew Gideon
  2010-11-29 23:05 ` Ray Morris
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Gideon @ 2010-11-29 22:37 UTC (permalink / raw)
  To: linux-lvm

I'm doing some manual pvmove-ing to reduce the amount of metadata stored 
for a VG.  But it occurs to me: Finding a good final layout, and a plan 
to get there, is the sort of thing at which computers are pretty good.

Is there a tool that will do this?

I did some searching, and all I found were suggestions to use pvmove.

	- Andrew

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

* Re: [linux-lvm] Tool for defragmentation of extends?
  2010-11-29 22:37 [linux-lvm] Tool for defragmentation of extends? Andrew Gideon
@ 2010-11-29 23:05 ` Ray Morris
  0 siblings, 0 replies; 2+ messages in thread
From: Ray Morris @ 2010-11-29 23:05 UTC (permalink / raw)
  To: LVM general discussion and development

   There is no official lvm2 defrag tool, I don't believe.
The first link returned by Google seems like it might be useful,
though it requires more manual work than one might expect.

http://bisqwit.iki.fi/source/lvm2defrag.html

   The above utility also fails to run properly on my system.
Working on a defrag tool might be a good way to contribute
without necesarily being an expert or committing to spending
a lot of time, since it could be done incrementally.  It seems
to me it should be pretty simple to generate a sequence of
pvmove commands which result in a reasonable defrag, if we assume
that neither the moves nor the final result have to be optimal.
(For some definition of optimal).  Later, the algorithm could
be improved to result in a better final or result and/or achieve
that result with fewer moves.

    Thinking about this last night, one interesting point is
that different layouts would be optimal for different purposes.
We resize LVs often, so our ideal result would leave some free
space at the end of each LV to be used for future expansion.
For other usage patterns, making all of the free space contiguous
might be better.

    Somewhat outside the scope of deframentation itself, but an
essentially similar task, realtes to the location of snapshots
versus the origin LVs.  We use a lot of snapshots and replace PVs
fairly frequently, so our ideal result would put snapshots on the
same PV as the associated LV.

    The bisqwit.iki.fi tool looks like it would work well with these
different ideas of an "optimal" deframented layout because it allows
the sysadmin to specify what the layout should look like in the end,
then the tool generates the necesary pvmove commands.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 11/29/2010 04:37:26 PM, Andrew Gideon wrote:
> I'm doing some manual pvmove-ing to reduce the amount of metadata  
> stored
> for a VG.  But it occurs to me: Finding a good final layout, and a  
> plan
> to get there, is the sort of thing at which computers are pretty good.
> 
> Is there a tool that will do this?
> 
> I did some searching, and all I found were suggestions to use pvmove.
> 
> 	- Andrew
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 
> 

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

end of thread, other threads:[~2010-11-29 23:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-29 22:37 [linux-lvm] Tool for defragmentation of extends? Andrew Gideon
2010-11-29 23:05 ` Ray Morris

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.