2

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 /etc/fstab.

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

as does lsblk:

# 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

Running 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:

# 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
Improve this question
3
  • What does sudo gdisk -l /dev/sdc show? Commented May 1, 2020 at 2:38
  • I've added to the original post. Commented May 1, 2020 at 2:48
  • By the way, the error that you got when running fsck was due to you specifying sdc rather than sdc1. Commented May 1, 2020 at 3:09

1 Answer 1

Reset to default
1

It seems as though you have a misconception as to the relationship between partitions and filesystems. Your partition is actually the correct size, but your filesystem is not.

When you ran pv < /dev/sda1 > /dev/sdc1, you copied the filesystem byte by byte from sda1 to sdc1. The filesystem was created on sda1, so mkfs.ext4 made the filesystem take up the exact size of sda1. However, sdc1 is larger than sda1. So the result is that you have a 10TB filesystem inside of a 12TB partition.

The solution is to use resize2fs to resize the filesystem such that it takes up the entire partition. You could pass an exact desired filesystem size to resize2fs, but this is unnecessary if you simply want it to be resized to the size of the partition. With /dev/sdc1 unmounted, simply run resize2fs /dev/sdc1 as root, and it should resize your filesystem to be 12TB.


Note:
You should use this type of filesystem copying sparingly; both the original and the copy will have the same UUID. If both partitions are in the system at once, the identifiers are no longer unique.

Thus, either use this method when you're going to wipe the source drive (i.e. you're just moving the partition to a new disk, not copying it), or if you plan to manually change the UUID of the copied partition.

Improve this answer
3
  • Gah! Thank you very much. I did look at resize2fs, but I assumed that since I had originally created the filesystem at 12TB, the copying would copy new data into, rather than on top of, this. What command, then, would tell me the size of the filesystem? That is, if I hadn't told you what I did, how would one discover that this might be the issue? Also: I was aware of the identical UUID issue; as I wrote above, I did manually create a new one after the copy. I used this method b/c the last time I did this via rsync it took about four times longer--days instead of hours. Commented May 1, 2020 at 3:25
  • @user9219182 As you observed earlier, df can tell you the size of the filesystem. About your first point, what do you mean by "I had originally created the filesystem at 12TB"? Are you referring to when you created the partition sdb1 at 12TB? Commented May 1, 2020 at 5:24
  • Um, right, df, obviously. And yes, I used mkfs.ext4 to create a 12TB filesystem on sdc1, before sda1 was in the picture, and when I originally ran df, it reported the correct size. So again, I assumed that even a byte-by-byte copy command would leave this filesystem intact. (I realize this was an incorrect assumption.) Commented May 1, 2020 at 9:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.