この種の質問がたくさんあることを知っていますが、何が起こっているのかわからないようです。 tl;dr: 既存のディスクをより大きなディスクに複製しましたが、dfパーティションテーブルが大丈夫に見えますが、元のディスクサイズでのみ表示されます。
私のDebianシステムには10TBのバックアップドライブがあり、その/dev/sda上に追加のバックアップとして12TBのドライブを追加しました/dev/sdc。最後に、オフサイトリポジトリの最初のバックアップを削除します。一度parted新しいパーティションを作成し、利用可能なスペース全体を使用して、mkfs.ext4その上にファイルシステムを作成しました。その後、このファイルシステムをマウントし、df -h予期した結果が表示されました。元のディスクは9.1T、新しいディスクは11Tでした。
ソースを新しいドライブにコピーしましたpv < /dev/sda1 > /dev/sdc1。これはレプリカなので、パーティションの新しいUUIDを作成し、uuidgenそれを使用して/etc/fstab。
新しいドライブには、私が期待するファイルがあります。ただし、df両方のドライブが同じとしてマークされます。
# 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
これは、ディスクが最初にマウントされたときに発生する現象です。ファイルを開いたままにする既存の操作とは異なります。
出力にはfdisk予想されるパーティション・サイズが表示されます。
# 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：
# 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パーティションのサイズが正しいことを確認するようでした。
# 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
だから一度試してみましたが、fsck結果はこんな感じです。
# 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
このオプションを試しましたが、e2fsck同じ結果が得られました。
df私はこのfsck問題に関するディスカッションを検索しましたが、役に立つものが見つかりませんでしたが、出力とディスクサイズの異なる表示の違いに関する多くのディスカッションのいくつかを見てきましたが、運度はあまり良くありませんでした。一般的にこれがそうです。理由は次のとおりです。新しいディスクに元のパーティションの正確なコピーがあることを確認してください。しかし、私のパーティションサイズは正しいようです。
どんな提案にも感謝します。私のファイルが新しいディスクにあるように見えるので、それを消去して再起動するには、再コピーに時間がかかります。
編集：要求に応じて出力は次のようになります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
答え1
パーティションとファイルシステムの関係について誤解があるようです。パーティションのサイズは実際には正確ですが、ファイルシステムはそうではありません。
を実行すると、pv < /dev/sda1 > /dev/sdc1ファイルシステムはバイト単位でコピーされsda1ますsdc1。ファイルシステムはに作成されるため、ファイルシステムは正確なサイズを占めますsda1。ただし、結果は12TBパーティション内の10TBファイルシステムです。mkfs.ext4sda1sdc1sda1
解決策は、resize2fsパーティション全体を占めるようにファイルシステムのサイズを変更することです。必要な正確なファイルシステムサイズを渡すことができますが、resize2fsパーティションサイズに合わせてサイズを変更したい場合は必要ありません。を削除して/dev/sdc1ルートとして実行するresize2fs /dev/sdc1と、ファイルシステムのサイズは12 TBに調整されます。
注：
このタイプのファイルシステムのコピーには、元のファイルとコピーの両方が同じUUIDを持つため、注意して使用する必要があります。両方のパーティションが同時にシステムにある場合、識別子はもはや一意ではありません。
したがって、ソースドライブを消去したい場合（つまり、パーティションをコピーせずに新しいディスクに移動する場合）、またはコピーしたパーティションのUUIDを手動で変更したい場合は、この方法を使用してください。