| View previous topic :: View next topic |
| Author |
Message |
meitnerium
Tux's lil' helper
Joined: 12 Feb 2003
Posts: 77
|
 Posted: Tue Dec 20, 2022 4:51 pm Post subject: XFS LVM with size smaller then PV size |
 |
|
I have a gentoo installed after CentOS installation. CentOS used LVM and XFS, and I'm not used to this configuration. I resized the disk to install gentoo and thinking about using the centOS home repertory on my gentoo installation. However, I am now unable to access the LVM partition. When I look at my LVM parition using lvs comand, I got this output :
| Code: |
# lvs
WARNING: Device /dev/sda2 has size of 3708838301 sectors which is smaller than corresponding PV size of 3904929792 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG cl have changed sizes.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-a----- 1.51t
root cl -wi------- 106.13g
swap cl -wi-a----- <5.88g
|
I resized my /dev/cl/home partition, but it look like it's not enough. I have now free space, but the PV size is the same. Does someone can explain me how to resize the PV? I can delete the root and swap partition.
Thank you for your help ! 
_________________
Voici la solution : http://www.perdu.com/ |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1659
|
| Posted: Tue Dec 20, 2022 5:00 pm Post subject: |
|
|
Read about the pvresize command and then execute it.
Be sure to have a backup if it contains anything valuable and try the --test option first. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Tue Dec 20, 2022 5:27 pm Post subject: |
|
|
meitnerium,
A LVM Physical Volume is a block device donated to LVM.
The next layer up is the Volume Group that comprises one or more physical volumes.
All this is hidden by creating Logical Volumes inside the Volume group.
Such Logical Volumes can be split over several physical volumes.
Physical Volumes are often named after the the block device that holds them. In your case, /dev/sda2, but they are not partitions.
Horrible things can happen when the block device is resized.
The physical volume still things it owns the original space it was allocated. The 'lost space' may still hold filesystem data.
The correct approach is to resize (reduce) the sizes of the layers from the top down to ensure that there is no data in the area of the PV to be reclaimed.
Conversely, when adding space, do it from the bottom up.
What to do about it.
If you wrote into the reclaimed space, then something in likely to be damaged.
If not, undoing the resize, should fix it because no data will have been harmed.
pvresize will change the size of the PV. Seen
| Code: | # pvdisplay -m
--- Physical volume ---
PV Name /dev/md127
VG Name storage
PV Size 21.83 TiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 5722928
Free PE 2242708
Allocated PE 3480220
PV UUID 9BMmYq-Kb8q-PhM1-fv1B-SLgj-80OI-7WlAzt
--- Physical Segments ---
Physical extent 0 to 524287:
Logical volume /dev/storage/home
Logical extents 0 to 524287
Physical extent 524288 to 652287:
Logical volume /dev/storage/distfiles
Logical extents 0 to 127999
Physical extent 652288 to 683007:
Logical volume /dev/storage/packages
Logical extents 0 to 30719
Physical extent 683008 to 2925714:
FREE
Physical extent 2925715 to 5722926:
Logical volume /dev/storage/media
Logical extents 0 to 2797211
Physical extent 5722927 to 5722927:
FREE
--- Physical volume ---
PV Name /dev/nvme0n1p3
VG Name nvmestatic
PV Size 931.33 GiB / not usable 1.69 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 238421
Free PE 157781
Allocated PE 80640
PV UUID HLkqt3-b2jB-mce2-urgD-8s0n-WTIh-4AkfyA
--- Physical Segments ---
Physical extent 0 to 511:
Logical volume /dev/nvmestatic/root
Logical extents 0 to 511
Physical extent 512 to 77311:
Logical volume /dev/nvmestatic/usr
Logical extents 0 to 76799
Physical extent 77312 to 78847:
Logical volume /dev/nvmestatic/var
Logical extents 0 to 1535
Physical extent 78848 to 79615:
Logical volume /dev/nvmestatic/opt
Logical extents 0 to 767
Physical extent 79616 to 79871:
Logical volume /dev/nvmestatic/local
Logical extents 0 to 255
Physical extent 79872 to 80639:
Logical volume /dev/nvmestatic/portage
Logical extents 0 to 767
Physical extent 80640 to 238420:
FREE |
Note that free space need not be at the end of the PV
My | Code: | PV Name /dev/md127
VG Name storage |
has its free space in the middle.
We need to establish exactly what you did, then undo it as long as you did not make any writes to the potentially doubly allocated space.
If you did make writes, how are your backups?
Your will be good so see. as it will show where the free space in the Physical Volume is.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21624
|
| Posted: Tue Dec 20, 2022 5:29 pm Post subject: |
|
|
| As I read this post, the PV may already be broken. I think OP shrank the containing partition (sda2) first, while the PV inside it, and the LVs inside that, and the filesystems inside those, still had their larger sizes. OP then proceeded to give the space reclaimed from sda2 to some other purpose, and probably overwrote it. If so, that would allow whatever sectors that are now outside sda2's smaller size to be overwritten, even if they had valuable data in them. Shrinking the PV may get rid of the warning, but I recommend validating the data inside the relevant LVs as soon as possible. |
|
| Back to top |
|
|
meitnerium
Tux's lil' helper
Joined: 12 Feb 2003
Posts: 77
|
| Posted: Tue Dec 20, 2022 8:01 pm Post subject: |
|
|
Thank you for your help. I was able to delete the root and the swap :
| Code: |
# lvremove /dev/cl/root
WARNING: Device /dev/sda2 has size of 3708838301 sectors which is smaller than corresponding PV size of 3904929792 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG cl have changed sizes.
Logical volume "root" successfully removed.
|
So now I must just have the home at the start of the partition.
| Code: |
# pvdisplay -m
--- Physical volume ---
PV Name /dev/sda2
VG Name cl
PV Size 1.66 TiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 435199
Free PE 38399
Allocated PE 396800
PV UUID lKkyPj-Ieaj-n9IJ-ixqs-iPFQ-JRFW-IpONch
--- Physical Segments ---
Physical extent 0 to 1503:
FREE
Physical extent 1504 to 398303:
Logical volume /dev/cl/home
Logical extents 0 to 396799
Physical extent 398304 to 435198:
FREE
|
And I am now able to resize using pvresize.
| Code: |
pvresize --setphysicalvolumesize 1700G /dev/sda2
/dev/sda2: Requested size 1.66 TiB is less than real size <1.73 TiB. Proceed? [y/n]: y
WARNING: /dev/sda2: Pretending size is 3565158400 not 3708838301 sectors.
Physical volume "/dev/sda2" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
|
However, The mount is still not woriking :
| Code: |
mount /dev/cl/home /mnt/oldhome/
mount: /mnt/oldhome: can't read superblock on /dev/mapper/cl-home.
|
_________________
Voici la solution : http://www.perdu.com/ |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Tue Dec 20, 2022 8:25 pm Post subject: |
|
|
meitnerium,
What did you do with the doubly allocated space after you shrank partition sda2 while it was still holding the original size PV named sda2.
The former is a partition, the latter is a LVM physical volume. They are different block devices.
Its quite possible that any write operations damaged the filesystem in /dev/cl/home
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
meitnerium
Tux's lil' helper
Joined: 12 Feb 2003
Posts: 77
|
| Posted: Tue Dec 20, 2022 9:53 pm Post subject: |
|
|
The sda2 partition have been shranked and a sda3 partition created. The partition have been formated as ext4 and gentoo installed on this partition. I have this message using dmesg:
| Quote: |
XFS (dm-1): last sector read failed
|
Yes, maybe I was wrong doing that. I didn't thinked about the LVM ... However, I am able to read file name using xfs_info /dev/cl/home.
Currently, I am running xfs_repair -n /dev/sda2. The output is
| Code: |
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
.................................................found candidate secondary superblock...
unable to verify superblock, continuing...
.........................................................................
|
With a lot more dot on terminal ...
_________________
Voici la solution : http://www.perdu.com/ |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Tue Dec 20, 2022 10:24 pm Post subject: |
|
|
meitnerium,
| Quote: | | The sda2 partition have been shranked and a sda3 partition created. |
That much was harmless.
Its just changing the partition table. Your data was not harmed.
| Quote: | | The partition have been formated as ext4 and gentoo installed on this partition |
These steps overwrite some of the space common to sda3 and the PV called sda2,
| Code: | --- Physical Segments ---
Physical extent 0 to 1503:
FREE
Physical extent 1504 to 398303:
Logical volume /dev/cl/home
Logical extents 0 to 396799
Physical extent 398304 to 435198:
FREE |
That free space | Code: | | Physical extent 398304 to 435198 |
is 147.560GiB.
How big was sda3?
I don't know XFS at all. I can only wish you good luck.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
Other Things Gentoo
