After backing up (step 1) and unmounting (between 2 and 3), run fsck
to ensure that the filesystem is healthy:
e2fsck -f /dev/mapper/ExistingExt4
Other than that, the steps are OK.
Purpose of the cryptsetup resize
command
what should I choose for $SECTORS? Is this step even necessary?
This step is necessary, otherwise the partition would still show up at the old side. This is confirmed with Nautilus, even after resizing with resize2fs
, the LUKS partition showed up as the old size. After running cryptsetup resize
, the correct number is shown. This step is not necessary. It only affects the current size status as shown in the file browser. After changing the size and closing/opening the partition again, the number is restored. So, when closing the LUKS partition as shown later will make this obsolete.
$SECTORS
can be determined by looking at the output of cryptsetup status ExistingExt4
:
/dev/mapper/ExistingExt4 is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sda2
sector size: 512
offset: 2056 sectors
size: 156049348 sectors
mode: read/write
(As of cryptsetup 2.0.0 (December 2017), the sector size may be larger than 512 bytes: see the cryptsetup(8)
manpage and the --sector-size
option.)
Thus, to subtract 15 GiB, use a sector size of 156049348 - 15 * 1024 * 1024 * 2 = 124592068
:
cryptsetup resize ExistingExt4 -b 124592068
Resizing the partition with parted
As for resizing the partition, parted
works fine with GPT partitions. The resize
command does not work however, as a workaround (or solution), remove the partition information and create a new partition as inspired by http://ubuntuforums.org/showthread.php?p=8721017#post8721017:
# cryptsetup luksClose ExistingExt4
# parted /dev/sda2
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) p
Model: ATA INTEL SSDSA2CW08 (scsi)
Disk /dev/sda: 156301488s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 34s 2082s 2049s Boot bios_grub
3 2083s 250034s 247952s ext2 RootBoot
2 250035s 156301438s 156051404s Everything
As 15 GiB has to be shaved off, the new end becomes 156301438 - 15 * 1024 * 1024 * 2 = 124844158
. Since I want to change partition 2, I first have to remove it and then recreate it with the label "Everything" (this could be changed if you like). Note: this disk has a GPT layout. For MBR, you should replace Everything
by primary
or extended
(untested, resizing a partition on MBR has not been tested and is not recommended because it is untested).
WARNING: the following commands has destroyed data. Do not copy it without understanding what is happening. The sector dimensions must be changed, otherwise you WILL destroy your partition(s). I am in no way responsible for your stupidness, BACKUP BACKUP BACKUP your data to a second storage medium before risking your data.
(parted) rm 2
(parted) mkpart Everything 250035s 124844158s
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? ignore
(parted) p
Model: ATA INTEL SSDSA2CW08 (scsi)
Disk /dev/sda: 156301488s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 34s 2082s 2049s Boot bios_grub
3 2083s 250034s 247952s ext2 RootBoot
2 250035s 124844158s 124594124s Everything
(parted) quit
In the above parted
example, my sectors are not aligned which is a mistake from an earlier installation, do not pay too much attention to it.
That is it! You can use cryptsetup status
and file -Ls /dev/...
to verify that everything is OK and then reboot.
resize2fs
doesn’t care about your deleted data. If it’s refusing to shrink your file system down to 200 GiB, it’s because it reckons it needs more room either to store the file system structure after the resize, or to perform the resize operation itself. You can see the details here (assuming you can read C); in summary:
- the file system needs enough room to store the required number of group descriptors, given the number of inodes;
- it needs enough room to store the data in the files;
- the resize operation needs extra inode tables for its background operations to ensure the resize will successfully complete;
- each inode group incurs some overhead, which must be accounted for (and can affect the way data is split across groups, requiring more groups and thus more overhead);
- space needs to be reserved to allow the extent tree to grow if necessary, and this can cause large amounts of overhead (especially when resizing, if there’s a lot of data in the part of the file system which needs to be cleared).
Some extra fudging overhead is added too (file system tools tend to play it very safe).
You can find out how small your file system can be made by running resize2fs -P
. resize2fs -M
will automatically make it as small as possible.
Best Answer
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 makesdumpe2fs
show super block info without a lot other unnecessary details. From the output, you need the block count and block size.Multiplicating these values will give the partition size in bytes. The above numbers happen to be a perfect multiple of 1024:
Since you want to shrink the partition by 15 GiB (which is 15 MiB times 1 KiB):
As
resize2fs
accepts several kinds of suffixes, one of them beingK
for "1024 bytes", the command for shrinking the partition to 62296032 KiB becomes:Without unit, the number will be interpreted as a multiple of the filesystem's blocksize (4096 in this case). See man resize2fs(8)