New answers tagged lvm
If you used a partition as an LVM PV then it doesn't matter whether the disk was partitioned as MSDOS or GPT. LVM does not operate at this level; it doesn't care at all where the block device came from.
Should point out that the above will wipe any data you have on /data. You'll also have to create a new file system on the new RAID0 partition (as per LVM example) and update your fstab so it is mounted as /data (or whatever)
I personally feel LVM is overkill for this simple task, I would suggest setting up mdadm to create a raid array. Now you have to options, either a linear array, which will literally produce a concatenated partition based on two source partitions, or raid0, which has the additional limitation that the source partitions must be of the same size but provides ...
You need to use LVM (Logical Volume Manager) First of all , you must be aware that if any of the physical disk fail , the Big 4TB volume will fail too. Backup your data first! Basically , all you need to do is to partition your data (/dev/sda2 and /dev/sdb1) partition in lvm format then : create two physical volumes (pvcreate /dev/sda2 /dev/sdb1) ...
As yoonix pointed out in the comment, the pvresize without options resizes physical volume to the size the operating system reports for the underlying partition. pvresize /dev/sdXY --setphysicalvolumesize option can be used to shrink the physical volume or to override the operating system autodetected size (if for some reason is wrong). To extend a ...
Even if it seems to non-match, aborting the resync should not alter your data that fast. If you are running a large-array (like 1TB disks), the resync normally takes hours, so aborting it should keep your data. In my case it worked, even if it seems to be mismatching. Whenever you get your raid running, keep in mind to backup your data afterwards and ...
From your pastebin output, I think you should try running: resize2fs /dev/mapper/ubuntu--vg-root You can run this command without any downtime.
Answer for reference. No, you can't. Or rather - you can, safely, but it will not work. Running 2nd pvmove for the same lv, will end up with: Skipping locked LV lv Skipping mirror LV pvmove0 All data on source PV skipped. It contains locked, hidden or non-top level LVs only. No data to move for vg You have to wait for the first one to finish before ...
You don't need to do anything else. Go shutdown and start the VM.
This is the way it looks when extending the lv but not the filesystem on top of it. Next step after having the size you want on the lv is growing the filesystem on there. This can be performed with resize2fs /dev/sdrive/shared .
Maybe device-mapper is 'stealing' this device. Try this: [root@host ~]# dmsetup ls sdb (253, 2) VolGroup00-LogVol01 (253, 1) VolGroup00-LogVol00 (253, 0) If you find sdb device listed as above example, remove it using dmsetup and create the physical volume: [root@host ~]# dmsetup remove sdb [root@host ~]# pvcreate /dev/sdb Physical volume ...
When assembling an array, both drive order and chunk size are of utmost importance. Please consider that, while Linux software RAID switched to use 512K-sized chunks recently, some years ago it used 64K-size chunks. This means that your previous array was probably created with the old default 64K-chunk. Retry to assemble the array using 64K chunks and ...
The rescan would probably have helped but to be honest, I cheated. I booted the VM to gparted-live-0.22.0-1-amd64.iso and expanded the partition. But I also needed to understand xfs_growfs. I went, xfs_growfs -d / and that was it. (I should have mentioned the file system type in the original post.)
When you extend your virtual disk, you need to do couple of changes to be visible. First, if you have done an online resize, you need to rescan the device: for i in /sys/class/scsi_device/*; do echo 1 > $i/device/rescan ; done Now, you will see your block device with new size. After that, if you have partitioned your drive, you have to extend ...
disclaimer: you should read lvm manual carefully and understand what each step does. however, there should be very little risk unless you encounter errors. this is what I do usually i this case. if there is a chance that someone else might do something to mess you up, you want to block any login while doing the maintenance (touch /etc/nologin etc. per your ...
Top 50 recent answers are included