Re: Additional warning:

We always face the requirements to add more warnings and remove them at the same time. In this case there already is a WARNING and lvreduce asked for confirmation.

Mentioning filesystem does not add any information in this case: if FS was not resized, lvreduce-ing the volume would damage ext4, or any other FS.

Recommendation:

Users should always use lvresize, lvextend and lvreduce with *-r|--resizefs* which ensures FS can be reduced, and does resize volume and filesystem in correct order (with the exception of cryptsetup/LUKS devices, which are not handled at the moment.)

Re: Repair:

To get the data back, the LV must be extended first - if there were no other LVs created on the disk, it may be possible to recover data - look at *vgcfgrestore* and restore from appropriate file in /etc/lvm/archive/. Even if there were LVs created it might work, if there were no data written to the new LVs (including metadata in case of thin-pool, mirror and RAID volumes, and in case of RAID volume leg synchronization.)

However, running resize2fs and xfsgrow was likely to further damage the FS. When repairing volume it is absolutely necessary to revert the steps one by one in reverse order (there may be exceptions), not going further - running fsck, or whatever else.

Hello Marian,

Thanks for the update.

I shared the details to customer, but still he expecting filesystem warning in the lvreduce command prompt. 

I explained him about the use case with -r option but he is not happy with this. 

If this feature adding possible, may I know what will be the estimated time.

Thanks
Jayaram

(In reply to Jayaram from comment #3)
> Hello Marian,
> 
> Thanks for the update.
> 
> I shared the details to customer, but still he expecting filesystem warning
> in the lvreduce command prompt. 
> 
> I explained him about the use case with -r option but he is not happy with
> this. 
> 
> If this feature adding possible, may I know what will be the estimated time.


lvm2 is universal volume manager - it's not oriented for XFS-only usage.
Thus lvm2 cannot know if the device content is the one user wants to still use,
or the one already 'disposed' and meant to be recycled for something else.

As primary warning - we show with BIG CAPITAL letters major warning the
size reduction may lead to significant data loss and it does not matter if there is extra string XFS, Ext4, or  i.e. some raw database content.

Running extra signature identification to tell which exact type of filesystem is actually there IMHO does not bring any more safety. AFAIK when the user always answers 'yes' anyway  it will not be any better if there will be 'XFS' word in the text.

It's the extra '-r'  option we provide to make filesystem (for couple types) 'aware'  resize operation - that's the primary purpose of '-r'.

So this request then looks like the customer here would like to have the option '-r' to be a default (always applied) logic?


BTW when a user realizes after the resize he made a wrong move - he can always go one step back with vgcfgrestore restoring previous metadata  (here it's mandatory  lvm.conf option  issue_discards is set to 0!  (please note that many wrong advices on the internet are suggesting here to use the value 1)
If such operation is made instantly after lvreduce - there is a big chance of minimal damage.

Hello Marian,

Please close this request. I explained customer about the scenerio and he happy with the "-r" option so we are good to close this BZ.

Thanks
Jayaram

Closing as suggested by reporter.