web-dev-qa-db-ja.com

qcowファイルで「ls -l」および「file」コマンドを使用したあいまいさ

ファイルシステムに qcow2ファイル があり、そのファイルのサイズを見つけようとしています。

このため、ファイルが保存されている場所でls -lを実行すると、13041664が返されます。これは、ファイルサイズが約13 MBであり、file <filename>を実行すると、

disk: QEMU QCOW Image (v2), has backing file (path 
/var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f), 21474836480 bytes

ファイルサイズは約21 GBであると推測されます。

これはコマンド出力の私の誤解ですか、またはファイルシステム内で何か他のものが行われていますか（シンプロビジョニングのようなもの）？

UPDATE：ls -l on var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626fを実行すると、ls: cannot access /var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f: No such file or directoryを取得し、そこにファイルがないことが正しい

UPDATE 2：qemu-img info <filename>の出力は次のとおりです。

image: disk
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 12M
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f512b73d (actual path: /var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f512b73d)
file-sizeqcow2
7
jobin

ウィキペディアの Qcow から：

Qcowディスクイメージの主な特徴の1つは、データが追加されるとこの形式のファイルが大きくなる可能性があることです。これにより、一部のファイルが空であっても、イメージスペース全体をファイルに割り当てるrawディスクイメージよりも小さいファイルサイズが可能になります。

したがって、ファイルサイズは実際には13MBですが、データが書き込まれると最大20GBになる可能性があります。例：

$ qemu-img create -f qcow2 test.img 2G
Formatting 'test.img', fmt=qcow2 size=2147483648 encryption=off cluster_size=65536 lazy_refcounts=off 
$ ls -l test.img 
-rw-r--r-- 1 carvalho carvalho 197120 Jul 18 09:30 test.img
$ file test.img 
test.img: QEMU QCOW Image (v2), 2147483648 bytes

空のqcow2ファイルが作成されました。 2GBのファイルシステムを保持できますが、現時点ではディスクの197KBしか占有していません。

から http://en.wikibooks.org/wiki/QEMU/Images ：

Qcow2の「牛」の部分は、コピーオンライトの頭字語です。これは、イメージを一度セットアップし、それを変更せずに何度も使用できる、すてきな小さなトリックです。これは、ソフトウェアの開発とテストに理想的であり、通常、最初に既知の安定した環境が必要です。 1つのイメージで既知の安定した環境を作成してから、複数の使い捨てのコピーオンライトイメージを作成して作業できます。

既知の良好なイメージに基づいて新しい使い捨て環境を開始するには、オプション-o backing_fileを指定してqemu-imgコマンドを呼び出し、コピーのベースにするイメージを指定します。使い捨て環境を使用してQEMUを実行すると、仮想ディスクへのすべての書き込みは、ベースコピーではなく、この使い捨てイメージに送られます。

qemu-imgマンページから：

オプションbacking_fileが指定されている場合、イメージはbacking_fileとの違いのみを記録します。この場合、サイズを指定する必要はありません。 "commit"モニターコマンド（またはqemu-img commit）を使用しない限り、backing_fileは変更されません。

例：

$ qemu-img create -f qcow2 -o backing_file=test.img test01.img
Formatting 'test01.img', fmt=qcow2 size=2147483648 backing_file='test.img' encryption=off cluster_size=65536 lazy_refcounts=off 
$ file test01.img 
test01.img: QEMU QCOW Image (v2), has backing file (path test.img), 2147483648 bytes

あなたの場合、/ var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f512b73dがバッキングファイルです。バッキングファイルなしでqcowファイルを使用しようとした場合、予想される動作はわかりません。

OpenStack ドキュメントの/var/lib/nova/instancesについて：

このディレクトリには、その計算ノードでホストされているインスタンスのlibvirt KVMファイルベースのディスクイメージが含まれています。共有ストレージ環境でクラウドを実行していない場合、このディレクトリはすべての計算ノードで一意になります。

/ var/lib/nova/instancesには2種類のディレクトリが含まれています。

最初は_baseディレクトリです。これには、その計算ノード上で起動された一意の各イメージについて、一目でキャッシュされたすべてのベースイメージが含まれます。 _20（または異なる番号）で終わるファイルは、一時的なベースイメージです。

他のディレクトリの名前は、instance-xxxxxxxxです。これらのディレクトリは、その計算ノードで実行されているインスタンスに対応しています。内部のファイルは、_baseディレクトリ内のファイルの1つに関連しています。これらは本質的に、元の_baseディレクトリから行われた変更のみを含む差分ベースのファイルです。

8
Eric Carvalho