Tag Info

Hot answers tagged

14

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. ... ...


7

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

The offset option of mount does not get passed to mount directly, but to losetup which sets up a loop device which refers to the offsetted location of the underlaying block device. Mount then performs its operations on that loop device rather than the raw block device itself. You can also use losetup to make resize2fs play which such file systems: # ...


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 ...


2

With 3.4 Gb free on root I don't think the free space is cause of the critical status. If you want to make space free on your root filesystem anyway, it is much more easy to copy some of the data to a special directory under /home and soft-link the original location to that copied data. Move the original location out of the way, then link in a one-liner, ...


2

It is not something I would do online but I think it is possible. I guess you are using ext4. umount /home $ umount /home shrink the /home filesystem $ fsck -f /dev/mapper/VolGroup-lv_home $ resize2fs /dev/mapper/VolGroup-lv_home 80G shrink the /home logical volume $ lvreduce -L -40G /dev/mapper/VolGroup-lv_home resize the /home partition to the size of ...


1

You cannot resize or change at all any partition on a storage device that is currently mounted. That means that your system needs to be shutdown if you intend to modify the root partition (since you cannot unmount it) You will need to boot in an external OS (e.g. using a live-CD) to perform these tasks. I would recommend you to backup any sensible data ...


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

The apparent answer is to run these two commands lvcreate --name opt --size 23Gi group mkfs -t ext4 -L opt /dev/group/opt However, via the comments thread it became apparent that lvcreate threw an error message, /dev/group/opt: not found: device not cleared Aborting: Failed to wipe start of new LV A search on Google finds that this is a known error, ...


1

Apart from Dylan suggestions to start over, another, non-intrusive option is to move some material from the root partition to the partition for the home directories. You should only do that for non-boot-critical material, but there is a lot of that in / outside of /home. My first Unix even had separate partitions for /usr and /var. You can copy e.g. ...


1

First, I create a partition type 8e(LVM) on /dev/sda3, and extend current volume group size by adding physical volume into volume group u64 vgextend u64 /dev/sda3. Second, extend logical volume root lvextend -L+22g u64/root. Third, resize the ext4 filesystem resize2fs /dev/mapper/u64-root. Similarly, extend the swap logical volume lvextend -L+3g ...


1

From what I can tell, ext4fs supports online defragmentation (it's listed under "done", but the status field is empty; the original patch is from late 2006) through e4defrag in e2fsprogs 1.42 or newer which when running on Linux 2.6.28 or newer allows you to query status for directories or possibly file systems, and at least defragment individual files. ...


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