Tag Info

Hot answers tagged

7

You should not use df because it shows the size as reported by the filesystem (in this case, ext4). Use the dumpe2fs -h /dev/mapper/ExistingExt4 command to find out the real size of the partition. The -h option makes dumpe2fs show super block info without a lot other unnecessary details. From the output, you need the block count and block size. ... ...


3

If you only changed the partition size, you're not ready to resize the logical volume yet. Once the partition is the new size, you need to do a pvresize on the PV so the volume group sees the new space. After that you can use lvextend to expand the logical volume into the volume group's new space. You can pass -r to the lvextend command so that it ...


3

Beyond the wear and tear on the HDDs I can't see any reason why this would be dangerous. I've never come across a EXT3/EXT4 parameter that limits the amount of times you can do this. There isn't any counter I've seen either. In looking through the output from tune2fs I see nothing that I would find alarming which would lead me to believe that performing ...


3

You must tell apart the resizing of a block device (here: /dev/sdb4) from the resizing of a file system. A file system can be smaller but not bigger than the underlying block device. You should make a backup of the partition table: sfdisk -d /dev/sdb > ~/sfdisk_sdb.txt Then you make a copy of that file and adapt the line that looks similar to this: ...


3

Extend your physical volume first, and then the logical volume: pvresize /dev/sdb4 lvextend /dev/vg_mine/lv_root Note that I've left off the -L+16G — this will use all free space.


2

If you shrinked your LV without shrinking your filesystem first, it's corrupt and the data on it is lost, since files were likely stored in the now longer accessible areas. Filesystems do not like this at all and you may not be able to repair it. If you didn't write any data yet to the other LV which now occupies the space, your best bet is to restore the ...


2

Enlarging a mounted volume has been officially supported for ext3 and ext4 for some time now. I don't know of any strong assessment regarding a change in safety. Obviously both the resizing and the other activities take even longer when done on parallel. But it seems strange to me that this takes so long. In my experience shrinking is slow but enlarging ...


1

I don't understand the problem. If the motivation for shrinking the partition is that you want to move it to another physical storage then the "shrinking magic" is: create the partition on the target storage format the new partition mount the partition (and the source partition) cp -a /path/to/source/. /path/to/target Much faster, much easier, less ...


1

Is /dev/sdb5 still a different partition? Then what you have to do is either repartition the space and combine /dev/sdb4 with /dev/sdb5. Oh I assume nothing is in /dev/sdb5 that is important because you're its going to be destroyed in the process. Another way, still destructive: - pvcreate /dev/sdb5 - vgextend ..... /dev/sdb5 - lvextend ..... - ...


1

Use gparted to move sdb2 toward the end of the disk, so that the free space is before it. Then you can resize sdb1.



Only top voted, non community-wiki answers of a minimum length are eligible