DD 出力イメージ ファイルはソース パーティションよりも大きく、DD はターゲット パーティション (イメージが作成される場所) がソース パーティションよりも大きいにもかかわらず、そのパーティションのスペース不足になります。
パーティションを同じディスク上の別のパーティションのファイルにコピーしようとしています。ターゲット パーティションは入力パーティションよりわずかに大きいです。両方ともext3パーティションです。
OpenSuse-Rescue LIVE CD から実行しています。Yast は、入力パーティション ( sdb1) が 62.5 GiB、出力パーティションがsdb262.85 GiB であることを示しています。
Thunar は、入力sdb1が 65.9 GB、出力がsdb266.2 GB であると表示していますが、出力ddイメージ ファイルも 66.2 なので、明らかに上限に達していますsdb2。
コンソールは次のとおりです。
(sdb1マウント解除されましたが、dd数回試しました)
linux:# dd if=/dev/sdb1 of=RR.image bs=4096
dd: error writing ‘RR.image’: No space left on device
16156459+0 records in
16156458+0 records out
66176851968 bytes (66 GB) copied, 2648.89 s, 25.0 MB/s
リクエストによる追加情報:
sdb1もう一度言いますが、ソース パーティションのサイズと、そこから作成された DD イメージ ファイルのサイズに違いがありますRR.image。そのファイルは にありますsdb2。
ここでまだ不明な点があります。DD を root として実行しているので、予約されたスペースに書き込みできるようになっていますよね? ターゲットはsdb262.85 GiB ですが、イメージの合計バイト数はおっしゃるとおり約 61.63 GiB です。コマンドの出力も次のとおりdfですPOSIXLY_CORRECT=1 df。
システムはsystem-rescue-cdです
root@sysresccd /root % df
Filesystem 1K-blocks Used Available Use% Mounted on
…
/dev/sdb1 64376668 7086884 56241208 12% /media/Data1
/dev/sdb2 64742212 64742212 0 100% /media/Data2
/dev/sdb3 5236728 4785720 451008 92% /usr/local
root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb1
Filesystem 512B-blocks Used Available Use% Mounted on
/dev/sdb1 128753336 14173768 112482416 12% /media/Data1
root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb2
Filesystem 512B-blocks Used Available Use% Mounted on
/dev/sdb2 129484424 129484424 0 100% /media/Data2
これを 2 で割ると、数値は単純な場合とまったく同じになりますdf。1024b/512b=2 が除数です。
sdb1は より小さいですsdb2。現在 100 パーセントの使用率になっているのは、sdb2DD イメージ ファイルがパーティションをいっぱいにしているためです。現在、このパーティションには DD イメージ ファイルしか存在しないはずです。イメージ ファイル自体は、DD (実行時) および Thunar レポートの時点で 66,176,851,968 バイトです。1024 バイトで割ると、64625832 K ブロックになりますが、正しいでしょうか? つまり、
dfレポートされたサイズsdb2よりも 116380K 以上小さく、sdb1(ソース) よりも大きいのですが、パーティションが最大になりますsdb2。
問題は、そのスペースを占めるものが何なのかということですsdb2。
しかし、最も重要かつ興味深いのは次の点です。
なぜターゲット ファイルは、ddそれを作成したソース パーティションよりも大きいのでしょうか。つまり、書き戻すことができないということです。
sdb1(64376668K) < RR.image(64625832K)
そして
sdb1(64376668 1K ブロック) < RR.image(64625832 1K ブロック) < sdb2(64742212 1K ブロック)
（計算が正しかったといいのですが…）
ここで、ROOT 用に予約されているブロックを確認しました。実行するコマンドが見つかりました:
root@sysresccd /root % dumpe2fs -h /dev/sdb1 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'
Reserved blocks: 1.6%
root@sysresccd /root % dumpe2fs -h /dev/sdb2 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'
Reserved blocks: 1.59999%
したがって、問題になる場合は、ROOT 用に予約されている割合も両方のパーティションで同じになります。
出力は次のとおりですgdisk:
root@sysresccd /root % gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdb: 312581808 sectors, 149.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DCF8AFC4-11CA-46C5-AB7A-4818336EBCA3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 2048-sector boundaries
Total free space is 7789 sectors (3.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 131074047 62.5 GiB 8300 Linux filesystem
2 131074048 262889471 62.9 GiB 8300 Linux filesystem
3 302086144 312580095 5.0 GiB 0700 Microsoft basic data
5 262891520 293771263 14.7 GiB 8300 Linux filesystem
6 293773312 302086143 4.0 GiB 8200 Linux swap
それで実際のサイズはどれくらいですかsdb1?
sdb2(N2) は (N1) より大きいのではないですかsdb1? では、なぜイメージ ファイルはsdb2(N2) より大きくなるのでしょうか? でルート用に予約されている領域をオフにすればsdb2、そこに収まるのでしょうか?
答え1
すべてのファイルシステムにはメタデータ用のスペースが必要です。さらにext、rootユーザーのためにスペースを確保しますデフォルトでは 5% です。
例
Kubuntu で 1GiB の (スパース) ファイルを作成しました:
truncate -s 1G myfile
その中にファイルシステムを作りましたext3。コマンドは単純です
mkfs.ext3 myfile
これにより、約 49MiB (この場合は約 5%) が に即座に割り当てられましたmyfile。ファイルがまばらで、実際のディスク上で最初は 0B の使用量が報告されていたため、それがわかりましたが、その後使用量が増加しました。これがメタデータが存在する場所であると想定しています。
ファイルシステムをマウントしたところ、df -h合計容量は 976MiB と報告されましたが、使用可能な容量は 925MiB しかありませんでした。つまり、残りの約 5% は使用できなかったことになります。
cdそして、このスペース（マウントポイントの後）を次のように埋めました。
dd if=/dev/urandom of=placeholder
通常のユーザーとして、私は 925MiB しか取得できませんでした。報告された「ディスク」使用量は 100% でした。しかし、 として同じことを行うとroot、ファイルに 976MiB を書き込むことができました。ファイルが 925MiB を超えても、使用量は 100% のままでした。
結論
この場合、パーティションのサイズを比較するのは間違いです。ファイルシステムのサイズを比較するのも間違いです。ターゲットの空き容量を確認しておく必要があります。ファイルシステム（例えばdf）とソースのサイズを比較するパーティション。
編集：
明確に言うと、66176851968バイトは約61.63GiBです。これはないソースパーティションの62.5 GiBよりも大きい。ソースパーティションターゲットが完全に読み取られなかったファイルシステム満腹になりました。
GB/GiBの区別がわからない場合は、以下をお読みください。man 7 units。
編集2
これで実際の数値がすべて揃いました。単位は512B一般的なセクター サイズである にしましょう。
- あなたの
sdb1パーティション131074048-2048=131072000ディスク上のユニットを占有します。これを と呼びますP1。これはgdisk出力からのものです。 - あなたの
sdb2パーティション262889472-131074048=131815424ディスク上のユニットを占有します。 としますP2。 これもgdisk出力からのものです。 - あなたのファイルシステム内部には合計 ユニット
sdb1までのファイルを保存できます128753336。この数を と呼びますF1。これはdf出力からのものです。 - あなたのファイルシステム内部には最大 単位
sdb2を格納できます129484424。 としますF2。 これもdf出力から取得されます。
P1との違いF1、およびP2との違いはF2、メタデータのための余地が必要であることを知っていれば説明できます。これについては、この回答の前の方で説明しました。
dd全体をコピーしようとしましたsdb1 パーティション、つまり、P1データをファイルに保存し、ファイルシステム内部sdb2、つまりF2利用可能なスペース。
P1> F2– これが最終的な答えです。画像ファイルは、必要以上に大きくなりませんでした。サイズは であると予想していたようですF1。実際、画像全体のサイズはP1単位になります。
P2そしてF1この文脈では無関係です。
答え2
長い議論の末、私はあなたの言いたいことを理解しました。
ようやく要点にたどり着きました。編集する前は、私の質問はちょっとわかりにくかったです。本当にありがとうございます!
パーティションの正確なサイズをバイト単位で取得する次のコマンドを見つけました:
root@sysresccd /root % parted /dev/sdb ユニット B p
モデル: ATA WDC WD1600AAJS-0 (scsi)
ディスク /dev/sdb: 160041885696B
セクターサイズ（論理/物理）：512B/512B
パーティションテーブル: msdos
ディスクフラグ:
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1048576B 67109912575B 67108864000B プライマリ ext3 ブート
2 67109912576B 134599409663B 67489497088B プライマリ ext3
4 134600457216B 154668105727B 20067648512B 拡張
5 134600458240B 150410887167B 15810428928B 論理ext4
6 150411935744B 154668105727B 4256169984B 論理Linuxスワップ(v1)
3 154668105728B 160041009151B 5372903424B プライマリ fat32 lba
したがって、基本的には、このリストの sdb1 (N1) の実際のサイズと、このリストの sdb2 (N2) の使用可能なスペースを比較する必要があります。
ただし、そのためには、ターゲット (sdb2) ファイルシステムで POSIXLY_CORRECT=1 df コマンドを使用します。この場合、ターゲットファイルシステムは 129484424 512b ブロックです。
sdb1 の 67108864000B を 512 b で割ると、131072000 512b ブロックになります。または、129484424*512 = 66296025088 バイトを掛けることもできます。
したがって、66296025088 バイト (sdb2 の使用可能スペース) < 67108864000 バイト (sdb1 の生のサイズ) です。明らかに、sdb1 パーティション イメージは sdb2 の使用可能スペースに収まりません。また、sdb2 には ROOT 用に予約されたスペースがあり、これも考慮する必要があります。
また、パーティションより大きいイメージ ファイルに関する私の質問については、基本的に、DD によって完全に読み取られる生のパーティション サイズではなく、sdb1 ファイルシステムのサイズを DD イメージと比較しました。正しいですか? 操作を完了するために必要なスペースを概算することもできます。66,176,851,968 バイトは不完全な DD イメージのサイズだったので、生の sdb1 パーティションのサイズと比較します。66,176,851,968 = 66176851968 B < 67108864000 B = 932012032 バイト小さい = 888 MiB
でも、空のパーティションには何が入っているのでしょうか? メタデータとルート用に予約されたスペースでしょうか? こんなにたくさんのスペースがあるなんて???!!!!! ありがとうございます!!
これらすべてを知って良かったです!!