which files, which physical volumes?

Hi there,

Is there any way to find which files in a given logical volume occupy extents on a given physical volume?

I am trying to decommission a drive and pvmove still isn't working properly. Either that or;

1. pvmove -tv claims to fail when in fact without the -t it would actually work. Thie would seem like a joke in very bad taste (on the part of the developers.

or

2. pvmove -v which is supposed to give verbose progress output, in fact will sit there for a *very* long time (half an hour or more) with no progress output and push load up extremely high.

Or maybe pvmove is *still* broken, in which case I need to find the files which occupy that physical volume, move them to a different logical volume altogether and then forcibly remove that physical volume without regard to the files that are no longer on it... and hopefuly this won't cause corruption on the filesystem on that logical volume.

help?

Thanks!

this will certainly cause corruption.

Luca Berra -- [email protected]
       Communication Media & Services S.r.l.
/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \

So is there any other way to decomission that physical volume that doesn't involve pvmove?

Actually, this just got more interesting because after the last pvmove --abort I now get this error out of pvmove -tv;

Insufficient contiguous allocatable extents (780) for logical volume pvmove0: 1292 required Allocation for temporary pvmove LV failed

which is new.

I am guessing here, but if I moved some of the larger files out of that logical volume, might pvmove be able to work around this?

LVM knows nothing of your files. It knows blocks, and it allocates them to Volume Groups and Logical Volumess without regard to whether or not the filesystem will use them.

Yours seems to be telling you that you can't move 1292 physical extents into 780. You'll have to add physical volumes (NFS mounted loopback? External USB harddrive?), or remove other logical volumes.

Or break the 1292 up into smaller parts if there *is* already room
elsewhere: the allocation routines don't do this for you yet.

e.g. pvmove /dev/hda:1000-1779
to move a specific 780 extents off hda.

[I suggest using version 2.00.24 is best for pvmove]

Alasdair

[email protected]

[snip]

[snip]

Well then its bogus; the physical volume I am trying to pvmove has a capacity of around 9G whereas the volume group of which it is a part has a nice 42G free.

So how does that work out to not enough extents?

Does the Volume Group in question have 42GB of unallocated extents, or 42GB free on the allocated Logical Volumes?

If you had VG main with 60GB total containing LVs lv1 and lv2 each 20GB then you'd have 2GB unallocated on the VG.

If you want more unallocated space on e.g. /dev/hdc1 (a member of VG main) to move part of lv1 onto (from /dev/hda1), you'd have to do something like:

resize_filesystem /dev/main/lv2 (down to smaller size)
lvresize -L (new size) /dev/main/lv2 # to resize the logical volume using the space pvmove -n /dev/main/lv2 /dev/hdc1 # to move as much as possible of lv2 off this PV pvmove -n /dev/main/lv1 /dev/hda1 /dev/hdc1

Does that make sense to you?

Michael T. Babcock

I end up using lvcreate (with some options) to create a new logical volume that has no extents on the physical volume you want to move off of, and has the exact same number of extents as the logical volume you want to move. Then use dd to copy the blocks from the filesystem you want to move (which has to be unmounted, or mounted read-only) onto the new one. Then unmount the old one, lvremove it, and change fstab and things so the new one is mounted in its place.

It's ugly and stupid. But, since pvmove doesn't seem to work yet, I think that's the best that can be done. I'm sorely disappointed that LVM2 was even put into the production kernel without pvmove working. :-(

I know LVM2 and the device mapper concept are much better than LVM1. But, pvmove is a core piece of functionality. It's like releasing a filesystem for which the lstat call doesn't work or something similar.

*sigh*,

"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper ([email protected]  http://www.omnifarious.org/~hopper) --

Unfortunately I don't have enough disk for this... nice idea though!

Phew! At least I am not the only one who feels like that!
This is for my home system, but at work, since discovering the non-workingness of pvmove, I have tried to make sure that we don't have to use it...

Absolutely. I am actually amazed that its still like this after so long.
I mean, whats the problem? Is Redhat blocking it somehow or what?
(I sort of sniff a scenario where Redhat have some proprietary volume management system in the pipeline and want to discourage people from using LVM2 so that they will be more likely to but into Redhat Enterprise Server or whatever, but maybe thats just paranoia speaking and I should just take the tinfoil hat off and let the rays in)

pvmove does work, but I am aware of the following restrictions if you want to avoid the risk of freezing:

You must not disable o_direct when configuring;
[I've heard some distributions/architectures may do this]
You must not set log activation to 1 in the config file;
[That settings's only needed for a particular sort of debugging]
You must not pvmove a filesystem that lvm itself uses directly;
[For 2.6.8 kernels, version 2.00.24 (if compiled against up-to-date headers that define O_NOATIME correctly) is reported to improve things substantially in this case; for 2.4 a kernel patch doing something similar gets applied by default.]
Don't try to mix snapshots with pvmove [untested].
I have also not tested with udev, nor with md underneath PVs.

Also:
The allocation algorithm is as yet unable to break up contiguous
space: you still have to break it up yourself if it doesn't find enough contiguous space. [e.g. pvmove /dev/hda:100-199]

Test mode works a different way in LVM2 - it's designed for testing and simply disables all writes at the lowest level of the code (to guarantee safety) - but reports success to the calling function. Many code paths don't yet say 'stop here if this is test mode' so they stop instead with an error when they find an inconsistency because they thought they changed something, but it got read back unchanged.

Alasdair

[email protected]

[snip]

wow it makes a lot more sense now.

This could really do with going into the pvmove man page, which is a bit sparse as it is...

Steve> Or maybe pvmove is *still* broken, in which case I need to find Steve> the files which occupy that physical volume, move them to a Steve> different logical volume altogether and then forcibly remove Steve> that physical volume without regard to the files that are no Steve> longer on it... and hopefuly this won't cause corruption on the Steve> filesystem on that logical volume.

You will destroy that filesystem, no ifs, ands or buts about it, if you just remove the phyiscal volume. Don't even think of doing it. Think about it for a seond, maybe in terms of layers.

You've got the physical disks on the bottom layer, with an LV on top of that, and a filesystem on top of that. If you remove any lower layer, you will immediately impact and probably corrupt the upper layers, unless you have the proper redundancy in the lower layer.

Sorry I can't help with the pmove stuff though, I haven't tried it yet.

John