I know this type of question has been asked frequently, but I cannot seem to figure out what is happening. tl;dr: I cloned an existing disk onto a larger disk, but
df is only showing this at the size of the original disk, even though the partition table looks OK.
I have a 10TB backup drive on my Debian system at
/dev/sda, and added a 12TB drive to serve as an additional backup at
/dev/sdc. Eventually I will remove the first backup, to offsite storage. I used
parted to create a new partition, using up the entire free space, and then
mkfs.ext4 to create a filesystem on it. I then mounted this filesystem, and
df -h showed me the expected result: The original disk was 9.1T, the new one was 11T.
I copied the original onto the new drive with
pv < /dev/sda1 > /dev/sdc1. Since this was a clone, I then created a new UUID for this partition with
uuidgen, and used this to mount the disk in
The new drive has the files I expect. However,
df now shows the two drives as being identical:
# df -h Filesystem Size Used Avail Use% Mounted on [...] /dev/sda1 9.1T 6.5T 2.6T 72% /mnt/Backup1 /dev/sdc1 9.1T 6.5T 2.6T 72% /mnt/Backup2
This is the case when the disk is first mounted; it's not like any existing operation is holding a file open.
The output of
fdisk shows that the partition is the expected size:
# fdisk -l /dev/sdc Disk /dev/sdc: 10.9 TiB, 12000105070592 bytes, 23437705216 sectors Disk model: Elements 25A3 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 96102C84-3B01-4361-A9C2-B44455AEC02E Device Start End Sectors Size Type /dev/sdc1 2048 23437703167 23437701120 10.9T Linux filesystem
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 9.1T 0 disk └─sda1 8:1 0 9.1T 0 part /mnt/Backup1 sdc 8:32 0 10.9T 0 disk └─sdc1 8:33 0 10.9T 0 part
parted also seems to confirm that the partition is the correct size:
# parted /dev/sdc GNU Parted 3.2 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: WD Elements 25A3 (scsi) Disk /dev/sdc: 12.0TB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 12.0TB 12.0TB ext4 primary
I then tried to let
fsck have a go at it, and got this:
# fsck.ext4 /dev/sdc e2fsck 1.44.5 (15-Dec-2018) ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdc The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> Found a gpt partition table in /dev/sdc
I tried the
e2fsck options, but got the same result.
I have searched for discussions of this fsck issue, without finding anything useful, and I have looked at some of the many discussions of discrepancies between
df output and other indications of disk size, also without much luck: usually the reason in this circumstance is that the new disk had an exact copy of the original partition. But my partition does seem to be the correct size.
I'd be grateful for any suggestions here. My files do seem to be on the new disk, so wiping it out and starting over again will take up many, many hours of recopying....
Edit: per request, output of
# gdisk -l /dev/sdc GPT fdisk (gdisk) version 1.0.3 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdc: 23437705216 sectors, 10.9 TiB Model: Elements 25A3 Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): 96102C84-3B01-4361-A9C2-B44455AEC02E Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 23437705182 Partitions will be aligned on 2048-sector boundaries Total free space is 4029 sectors (2.0 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 23437703167 10.9 TiB 8300 primary