lvreduce question

[Luca Rasconi]

Somebody knows where I could find doc about how lvreduce internally works?

What is the relation between lvreduce and VxFS filesystem?

Thank you and bye
L.

[James R. Ferguson]

Hi:

A logical volume is a container for a filesytem. In the case of VxFS filesystems, where the Online component license of JFS is available, one uses 'fsadm' to first reduce the size of the filesystem and then 'lvreduce' to secondarily reduce its container (logical volume). Unless you are running JFS version 3.3, reduction may not succeed. Defragmentation of the filesystem before attempting the resizing may increase the success, however.

In the absence of the Online JFS license, a VxFS filesystem may be reduced by taking a backup of the filesystem (e.g. to tape); doing an 'lvreduce' [which is considered to be destructive of the whole filesystem]; then creating a new filesystem ('mkfs -F vxfs....') and restoring the newly created filesystem from the backup first taken.

Regards!

...JRF...

[Brian M Rawlings]

Luca:

From the HP-UX man page for lvreduce:

http://www.docs.hp.com/hpux/onlinedocs/B2355-90681/B2355-90681.html
...
The lvreduce command reduces the number of logical extents allocated to a logical volume specified by lv_path. The excess physical extents in the logical volume and any mirror copies are deallocated.
Alternatively, it reduces the number of mirror copies in the logical volume. The physical extents that comprise the deleted mirror copy or copies are deallocated. If pv_path ... is specified, the mirror or mirrors to be removed will be deallocated from those specific physical volumes.
...
LVM does not store any information about which physical extents within a logical volume contain useful data; therefore, reducing the space allocated to a logical volume without doing a prior backup of the data could lead to the loss of useful data. The lvreduce command on a logical volume containing a file system of greater length than the size being reduced to will cause data corruption.
...

I don't think this is the in-depth "internals" info you are looking for, and I'm not sure where that is.

As far as the relationship, a LVOL provides a virtual structure for a file system to live in/on, when not using the "whole disk is a volume" approach to disk partitioning.

The LVOL provides the physical space within a volume group, in the form of logical extents (large data blocks allocated out of the entire pool of storage contained within the VG, and mapped through the LVM metadata that defines its structure, space, sizes, etc).

The lvreduce command deallocates extents from a LVOL, or eliminates mirror copies of those extents to another disk in the VG. The extents thus freed up are then available to extend other LVOLs, or to create new ones, within the VG.

If there is a file system in an LVOL, and you deallocate extents that were used by that file system (vxfs or otherwise), it is corrupt and must be recreated. The VxFS allows for growing or shrinking a file system on the fly, so that you can reduce the LVOL on the fly if you care to, but...

If you search through this forum, you will find that the common assertion is that it is OK to grow data structures like LVOLs and VxFS file systems on the fly (with a backup first), but that nobody recommends reducing them that way. There are uncertainties about which extents contain data, and which will be deallocated, and that is enough to make most people avoid this activity.

In my experience, occasionally, somebody will go ahead and try on-line reduction via fsadm_vxfs and lvreduce, and some have gotten away with it. Once. Maybe twice. But pretty much everyone has gotten burned at some point by this practice, and then they don't do it anymore. I myself have "learned from the mistakes of others", and have not, and never intend to, do online reductions.

Maybe I've answered your question, and maybe I'm way off. If not, please be a little more specific about what you are uncertain about, and I (or someone more knowledgeable) will take a shot at helping you further.

Best Regards, --bmr

[Luca Rasconi]

Thank you for your answer, let's continue the discussion.

I use HP-Online JFS.

I know that if try to reduce a LV to a size smaller than the fs size, surely I lost my data, because there are useful data within the PE cutted by lvreduce and lvm doesn't now about useful data in the PE.
But if I reduce a lv to a size BIGGER than the fs size contained in the lv, is there some probability that data were lost?
That is, does lvreduce know the PE used by the file system?


Thank you again

L.

[Pete Randall]

As JRF pointed out, JFS versions prior to 3.3 may have issues and your best hope is to do a defrag first. I was so disheartened by this fact when I first got OnlineJFS that I've gone back to the old-fashioned method of backup, reduce restore, or re-create a new file system of the correct size and re-mount it as the old.

Pete

[James R. Ferguson]

Hi (again):

No, to the best of my knowledge LVM has no knowledge of how the filesytem has "chosen" to occupy physical space granted it.

Thus, if you created a logical volume of (for example) 100-extents but created a filesystem within it of only 50-extents; then you *could* 'lvreduce; the logical volume to 50-extents without corruption of the filesystem data. That is because there was never any utilization of extents 51-100 by the filesystem structures.

When an Online JFS 'fsadm' downward resize is done, the process insures that no filesystem data occupies physical address space that maps to physical extents that can then be freed ('lvreduced').

Regards!

...JRF...

[Robert-Jan Goossens]

Hi Luca,

I hope i understand your question, if you are reducing your Logical Volume "bigger" i beleave you have to use lvextend instead of lvreduce and then your answer to the question "will lvextend know your physical limit" is yes it will extend your LV to the maximum physical extend possible (whithin blocks of 4 MB)

kind regards

RJ