+1、私はこの主題に関するいくつかの議論を聞くことに非常に興味があります。 これまでの私の戦略は

• 何を構築/プルするかに注意してください
• / var / lib / dockerを吹き飛ばす準備をしてください：neutral_face：

@AaronFriel 、どのバージョンのDockerを使用していますか？ 0.7.1？

/ cc @regilero （＃2276にもリンク）

新しい/ var / lib / dockerから開始：

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
292M -rw-------. 1 root root 100G Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/json
732K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

次に、dockerがbusyboxをプルした後、少し大きくなりました。

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
297M -rw-------. 1 root root 100G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/json
756K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

docker rmibusyboxはファイルを大きくしませんが、devicemapperプールの空き容量を増やします。

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

イメージを再度ダウンロードしても、ループバックファイルは大きくなりません。

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

したがって、thinpデバイスがブロックを破棄すると、ループバックファイルの再スパース化に失敗したようです。

ただし、コンテナのfsイメージ内にファイルを作成すると、ループバックファイルのスペースが再利用されます。
つまり、busyboxの画像でこれを行いました：

 cd lib
 cat libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 lib
c.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so
.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 > a_file.bin
/lib # ls -l a_file.bin
-rw-r--r--    1 root     root      47090160 Dec 12 16:41 a_file.bin

これにより、データファイルが299Mから344Mに増加しました。 しかし、a_file.binを削除すると（そして少し待って）、299Mに戻りました。

だから、これはデバイスマッパーのバグのように私には思えます。 つまり、thinpデバイスから基になるデバイスに破棄を転送しますが、プールからthinpデバイスを削除するときに破棄しません。

これはカーネルの問題のようです。BLKDISCARDを使用して回避することを検討していましたが、失敗しました。 詳細については、このバグを参照してください： https ：

回避策はhttps://github.com/alexlarsson/docker/tree/blkdiscardにありますが、これよりもうまくいくかどうかはまだ調査中です。

この問題に関する上流のdmコメント：
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

Docker 0.7.0を使用するCentOS（2.6.32-358.23.2.el6.x86_64）でもこの問題が発生します。 古いですが、問題はUbuntuに限定されていません。

Arch GNU / Linux 3.12.6-1-ARCH、Dockerバージョン0.7.2で同じ問題。

CentOSの0.7.0にはまだ存在します。

ubuntu 12.04.3LTSの0.7.2にまだ存在します。

スペースの多くはdocker/devicemapper/devicemapper/dataとmetadataにありますが、 docker/devicemapper/mnt

docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfsでコンテナファイルシステムを見ることができることを私が学んだのは素晴らしいことです

しかし、私のハードディスクがほぼ完全に使い果たされ、 rmdir -r dockerしか修正できないのは良くありません。

rspec-systemのdockerサポートを書いているときに同様の問題が発生しています。 テストVM（Dockerホスト）には8GBのドライブがあり、イメージを削除せずに繰り返し作成した後、ドライブがいっぱいになります。 ただし、すべてのイメージとコンテナを削除した後でも、ドライブは100％いっぱいです。 ID-10Tエラーだと思いましたが、VMをあきらめて破壊しました。

ubuntu13.04の0.7.5にまだ存在します。

この問題は、最近マージされたPR＃3256によって修正されました。 この修正は、将来のリリースに含まれる予定です。

修正がマスターにマージされたため、この問題を解決します。

注：ITSは_fully_あなたもしてカーネルを実行するまで固定されていないhttp://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=その中の

スペースを削除するための回避策は何ですか。 私はrhel6.5を使用していますが、新しいカーネルを入手するのに時間がかかる場合があります。

私のiPhoneから送信された

2014年1月21日午前6時18分、AlexanderLarssonnotifications @ github.comは次のように書いています。

注： http：//git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/？h = for-next＆id =でカーネルを実行するまで、完全には修正されません。6d03f6ac888f2cfc9c840db0b965436d32f1816d 。 それがなければ、Dockerの修正は部分的なものにすぎません。

—
このメールに直接返信するか、GitHubで表示してください。

@logicmindsスペースATMを回復するための超簡単な方法はありません。 技術的には、ループバックファイルを手動で再スパーシングできるはずです。 ただし、これには、使用されていないすべてのブロックをゼロにするか、スパース領域を簡単に検出するための何かが必要になります。これは、シンプデバイスの削除では行われません。

@alexlarssonこれは

@logicmindsそのコミットがアップストリームカーネルにあるかどうかさえわかりません。 そのリンクは、デバイスマッパーツリーからのものです。 それは間違いなく3.8ではありません。

スペースを取り戻すために使用できるfstrimのようなツールを作成することを検討しています。

@alexlarssonの問題https://bugzilla.redhat.com/show_bug.cgi?id=1043527は、「データが不十分」であるため、正式にクローズされました。 それは、パッチがカーネルに組み込まれないことを意味しますか？ それはまだ必要ですか？

@vrvolledockerが使用する回避策を作成するパッチはすでにアップストリームにあります。 ただし、その回避策を不要にする上流の作業はないようです。

デフォルトの2.6.32カーネルを使用するcentos6.5のdocker0.9でも、この問題が発生します。

デバイスマッパーへのこのコミットについて以前にあなたが言ったことを理解するのはよくわかりません。 カーネルを3.8に移行すると、このバグが解決されることを確認できますか？

前もって感謝します。

@ nicolas-vanいいえ、このコミットが必要です： https ：

これは3.14にあり、さまざまな3.xyバックポートにある可能性があります。

少し前にdockerをインストールして、イメージを作成し、コンテナー内で実行しました。 その後、しばらくして、Dockerアプリケーションとメインフォルダーを含むすべてのイメージとコンテナーをクリアしました。
合計4GB / 24GBの空き/使用済み（df -h）のうち、コマンドdu / -shは10GBしか報告しないため、別の10Gbは考慮されていないことに気付きました。 これは、dockerで生成された一時イメージのサイズよりも小さいですが、このバグに関連している可能性があります。 私はcentos6.5とdocker0.9を使用しました。

dockerをyumで削除し、devsを/ dev / mapper / docker *からdmsetupで削除し、rm / var / lib / docker -Rfも削除しましたが、df10gbを使用したディスクレポートはどこにも見つかりません。

@Jacqファイル記述子が開かれているプロセスによって、一部のファイルがまだ存続している可能性があります。 再起動しましたか？ それはそれが起こらないことを保証するでしょう。

Linux3.14.4-1-ARCHとdocker0.11.1を実行し、すべてのイメージとコンテナーを削除しました。
ファイル/ var / lib / docker / devicemapper / devicemapperがスタックし、約1.5GBを消費します

これは、mongodbのものをいじった後の出力ですが、/ varがそれほど大きくないため、ファイルサイズをまばらに割り当てる必要があると思います。

~/w/e/video_history ❯❯❯ docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-254:3-585-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 948.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 1.0 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.4-1-ARCH
WARNING: No swap limit support
~/w/e/video_history ❯❯❯ sudo ls -alh /var/lib/docker/devicemapper/devicemapper/data
-rw------- 1 root root 100G Jun  4 14:35 /var/lib/docker/devicemapper/devicemapper/data
~/w/e/video_history ❯❯❯ sudo  du -shc /var/lib/docker/devicemapper/
1.6G    /var/lib/docker/devicemapper/
1.6G    total

すみません、バグは修正されましたか？ 私はgentooでそれに遭遇しました。

@bolasblack gentooを実行して、この問題に遭遇しました。 あなたは何かを理解しましたか？

x86_64用に3.14.14である最新のgentoo-sourcesを使用しています。 https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diffを調べたところ、そのパッチがソースに適用されています。 Dockerバージョン1.1.0、ビルド79812e3を使用しています。

@alexlarssonこのような長い期間の後に、このクローズされた問題に注意を戻してくれてありがとう。 まだ問題が発生しているようです。 ＃4202の状況について何か教えてください。

これはまだ問題です！ とりあえずAUFSの使用に戻すつもりだと思います。

@daniellockard AUFSは非公式に非推奨になっているようです：＃783と＃4704、それで頑張ってください。

Yikes ...その25GBはどこに行きましたか？ ああ、その1つのファイルに....私はカーネル3.16.2 f2064bを実行しています

「回避策」へのリンクが壊れています...それは何ですか？ そして私のカーネルはそれをサポートしています... Torvaldsが3.14でコミットした場合、fedoraは3.16でそれを見るはずだと思います。

+1

+1

+1

+1それでもUbuntuTrusty、3.13.0-36で発生しているようです-Dockerバージョン1.3.1で一般的、ビルド4e9bbfa

Trustyでも+1。 3.16を使用する14.10で確認する価値はありますか？

@SvenDowideit @shykes @vieux @alexlarsson @Zolmeister @creack @crosbymichael @dhrp @ jamtur01 @tianon @erikh @ LK4D4

これはばかげているので、トップコミッターにタグを付けます。 これについての公開の会話と、このバグが定期的に壊れて再作成する必要があるコンテナまたはシステムにつながる可能性があることをDockerのチームから認める必要があります。 ビルドボットのチャーンが非常に多いため、Dockerホストを毎週または2週間定期的に再イメージングするなど、非常識なdevopsソリューションを実装しなければならなかった人が何人かいることはすでに知っています。 私はこの問題を1年近く前に紹介しましたが、私が知る限り、決定的なソリューションは作成されておらず、表面上はサポートされている古いカーネルはサポートされていません。

Dockerチーム：調査を行って、影響を受けるカーネルバージョン、その理由、および問題を修正するパッチを特定し、文書化してください。 その情報を、サポートしているカーネルバージョンとともに公開します。これは、Dockerのコンシューマーがこの問題に何度も何度も悩まされているためです。これは、この問題に関するメールが毎週1、2週間届いていることからもわかります。 真剣に、これは重大な問題であり、1.0より前から問題となっています。

私が見ているように、この問題を+1するために受信し続ける電子メールを停止する、満足のいく方法でこの問題を修正するためのいくつかの可能なオプションがあります。

1. サポートされていないカーネルでDevice-Mapperが使用されている場合はユーザーに通知し、スペースを再利用する方法の詳細な手順をユーザーに提供し、可能であれば、Dockerでこれを行うプロセスを自動的に設定します。 この問題が発生しているホストに対してdockerCLIを使用する場合にも、この通知を発行することをお勧めします。これにより、docker CLIからホストをリモート管理するときに、一部のホストがスペースを正しく再利用できない可能性があることがユーザーに通知されます。
2. 問題を（どういうわけか）修正します。 私はカーネル開発についてこれが何を伴うのかを知るのに十分なことを知りませんが、私の初心者の読書に基づいて、私はこれを提案します：

a。 デバイスマッパーはカーネルモジュールであるため、機能的で動作するバージョンをdm-dockerようなものとしてDockerソースツリーに取り込み

b。 dm-docker十分な変更を加えて、デバイスマッパーと共存できるようにします。

c。 影響を受けるプラットフォームでは、インストール時にdm-dockerカーネルモジュールをインストールし、デフォルトでdm-dockerます。

1. インストールドキュメントとdocker.comサイトを修正して、影響を受けるカーネルバージョンに関する警告を含め、パッケージにランタイムチェックを追加して、デバイスマッパーの正しい動作を確認し、そうでない場合はユーザーに報告します。

これは、Dockerの次の安定版リリースのブロックの問題になるはずです。なぜなら、Dockerをパントし続けて、ユーザーを慌てさせることはまったく受け入れられないからです。

個人的には、CoreOSはDocker用の唯一の安定したLinuxディストリビューションだと思います（この問題が解決されるまで）。

Dockerチーム：この問題の原因がコンポーネントではないことはわかっていますが、他のLinuxディストリビューションでもソフトウェアを使用できるように支援してください。 この問題をDockerのよく知られた制限としてドキュメントに記載して、他の人が時間を無駄にしないようにできれば問題ありません。

ありがとう！
マーティン

+1何かをする必要があります。

（クローズされた）githubの問題リストを掘り下げるよりも、この問題についてもっと明白なことがあればいいのにと思います。 これが根本的な問題であることを実際に発見するのに長い時間がかかり、この問題を可視化できればよかったと思います。

私たちの上流のデバイスマッパー開発者（私自身とJoe Thornber）は、この問題が依然として人々の問題であることを完全に_ゼロ_認識していました。 私たちが見る、私たちはそれを知らされた後（2013年12月における@alexlarssonバックで）すぐに問題を修正し、その時点で_all_安定カーネルに含めるためにそれをタグ付け： http://git.kernel.org/linus/19fa1a6756ed9e9 （ "dm thin：以前に共有されたブロックへの破棄サポートを修正"）

Joe Thornberは、 @ alexlarssonがdockergoコードにtrim-poolを実装していることに
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

つまり、アップストリームコミット19fa1a6756ed9e9（ "dm thin：以前に共有されたブロックへの破棄サポートを修正する"）を持たないカーネルを実行しているユーザーは、より適切にサポートされるカーネルを実行することによってそれを修正する必要があります。 簡単にメモを[email protected]に送信して、修正がない安定したカーネルに修正を埋め戻すことができます。 したがって、この修正が適用されていない安定したカーネルがある場合は、それをお知らせください。

今後は、dockerが使用しているシンプールデバイスに対して定期的に「thin_trim」を実行するようにします。 しかし、「thin_trim」がディストリビューションで広く利用可能になったら、その橋を渡ります。

@shabbychef @daniellockardいいえ、AUFは非推奨ではありません-最初に、これらの問題の1つだけが閉じられ、読んでいると、 https： //github.com/docker/docker/issues/783#issuecomment-38731137は読む価値があります：

Our initial plan was to phase out aufs completely because devmapper appeared
 to be the best option in 100% of cases. That turned out not to be true, there 
are tradeoffs depending on your situation and so we are continuing to maintain both.

@snitm hack/check_config.shに何かを追加して、カーネルにこのパッチがないことをユーザーに伝えることができますか？

@SvenDowideit残念ながら、問題の変更は任意のカーネルで識別されていません。 初心者の場合、コミット19fa1a6756ed9e9は、シンまたはシンプールターゲットのバージョンをバンプしませんでした。 しかし、それが行われたとしても、そのバージョンはすべての安定したカーネル間で異なります（したがって、「安定した」コミット内のバージョンバンプは悪いです..コミットがバックポートされるすべてのカーネルの手動編集の原因となるため）。

ただし、シンおよびシンプールのターゲットバージョンが1.12.0以上のユーザーは、すべて修正されます。 したがって、カーネル> = 3.15です。 ユーザーが実行しているDockerには、

参考までに、「dmsetupターゲット」を実行すると、シンプールターゲットバージョンとシンプールターゲットバージョンが一覧表示されます（dm-thin-poolカーネルモジュールがロードされている場合）。

これに注意を払ってくれてありがとう。 先週のRe：Inventのブースの男にそれについて話しました。

@snitmなので、 dmsetup targets出力をcheck-config出力に追加する必要がありますか？

@snitm

シンプロビジョニングされたデバイスマッパーデバイスを作成し、パッチが適用されていないカーネルの空き領域を再利用できない操作を実行し、それに基づいてステータスコードを報告する自動テストを作成することは可能でしょうか？

@SvenDowideitループバックの上にDMシンプロビジョニングを利用し始める前に、問題のある新しいカーネルをキャッチしたいと

@AaronFrielは範囲が非常に狭いようで、この特定の修正にこだわっています。 DMシンプロビジョニングのエンタープライズグレードの展開には、この修正が実施されていることを確認するだけではありません（残念ながら現実）。 DMシンプロビジョニングターゲットでは、コミット19fa1a675がアップストリームに移行して以来、多数のエラー処理、パフォーマンス、および機能の改善が見られました。 これらはすべて、DMシンプロビジョニングを本番環境に展開するときに重要です。

ですから、一歩後退して、レイヤード製品はすべての基礎となるレイヤーと協調して開発する必要があることを理解している会社で働くことを楽しむことができます。 また、DockerとペアになっているN個の任意のカーネルのDMシンプロビジョニングをサポートすることにほとんど関心がありません。

そして、私はたまたま、ループバックデバイスをバッキングデバイスとして使用するDMシンプロビジョニングを使用するべきではないと_強く_信じています。 これは完全なハックであり、「これは本番環境ではどのように見えるか」を適切に制限したり心配したりすることなく、Dockerに統合されました。

DMシンプロビジョニングにDockerを適切にデプロイするには、lvm2ベースのシンプロビジョニング構成が提供するエンタープライズ指向の管理機能が必要であることに気付きました。 そのことを念頭に置いて、私は新しいハイブリッド管理ソリューションを機能させることに着実に取り組んできました。次のPRを参照してください。
https://github.com/docker/docker/pull/9006

この作業は以下に依存します：
1）lvm2> = 2.02.112
2）DMシンプールターゲットバージョン> = v1.14.0（別名、Linuxでステージングされた変更-Linux 3.19を含む次のバージョン）

RHEL7.1にはこれらの変更があります。 そして、RHELAH（アトミックホスト）もそうします。 DockerをDMシンプロビジョニングに適切にデプロイしたい他のディストリビューション/製品もそうすべきです。

@snitmええ-私は、

そして、あなたの残りの情報の文脈で-私はこの恐ろしい驚きを引き起こすカーネルの数を減らしたいです:)

@SvenDowideit OK、このコメントで、docker（またはそのユーザー）がループバックの互換性に関するDMシンプをチェックするために使用できる情報を提供しました： https ：

@ snitm 、@ AaronFriel
AWS Beanstalk、AmazonAMIでこの問題のように見える問題が発生しています。
（スペースが不足しています）
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64＃1 SMP Tue Nov 11 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudodockerバージョン
クライアントバージョン：1.3.2
クライアントAPIバージョン：1.15
Goバージョン（クライアント）：go1.3.3
Gitコミット（クライアント）：c78088f / 1.3.2
OS / Arch（クライアント）：linux / amd64
サーバーバージョン：1.3.2
サーバーAPIバージョン：1.15
Goバージョン（サーバー）：go1.3.3
Gitコミット（サーバー）：c78088f / 1.3.2

Ubuntu14.04とDocker1.4.1でもこのエラーが発生します。

シンプールとシンバージョンが1.12.0以上であることを期待しないでください。問題がないことを意味します。2.6.32-431.29.2.el6.x86_64カーネルでCentOS6.5 VMを実行しており、dmsetupターゲットは次のように報告しています。 thin-poolとthinはどちらもv1.12.0です。 しかし、私は自分自身を解放していない40GBのデータファイルで立ち往生しています。

このバグでCentOS / RHEL 6.5でこれを実行するとどのような影響がありますか？ 100G以上の空き容量で大丈夫ですか。 私はこれが最終的に任意のサイズのディスクを満たすと思いますか？ それとも100Gで制限されていますか？

6.5にはcentosで利用できる最新のカーネルがないことに注意してください。 6.6への単純な「yumupdate」と2.6.32-504.3.3カーネルでテストするための再起動をお勧めします。

CentOS 6の最新のカーネルとディストリビューションの更新が正常に機能し、スペースが解放されることを確認します。

ripienaar：使用しているCentOS 6とカーネルのバージョンを明示的に述べることはできますか？ 情報を渡すときに、必要なすべての情報が揃っていることを確認したいだけです。

ありがとう。

@reizが上でコメントしたように、これは最新のUbuntu Dockerで発生しています。 dmsetupターゲットは、インスタンスの1つでv1.9.0のシン/シンプールを表示します（アクティブなDockerコンテナーはありません）。dmsetupターゲットは、アクティブなDockerコンテナーを持つ同様のインスタンスでシンエントリを表示しません。 （私はこれについて実際に助けを求めているのではなく、（うまくいけば）データを追加するだけです。）

基本的なOSのもの：

# uname -a
Linux vagrant-centos65 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release
CentOS release 6.6 (Final)

# dmsetup targets
thin-pool        v1.14.0
thin             v1.14.0
mirror           v1.12.0
striped          v1.5.6
linear           v1.1.0
error            v1.2.0

# dmsetup status
docker-8:1-393542-pool: 0 209715200 thin-pool 92343 178/524288 4664/1638400 - rw discard_passdown queue_if_no_space

使用法：

# du -h /var/lib/docker/
2.7G    /var/lib/docker/devicemapper/devicemapper
# docker rmi b39b81afc8ca
# du -h /var/lib/docker/
2.5G    /var/lib/docker/devicemapper/devicemapper

そのカーネルに入る前は、スペースを回復しませんでした。

@jperrinは、これがcentosカーネル2.6.32-504.3.3を使用して解決されると述べています。 この問題を解決するカーネルコミット（コミットのセット？）はわかっていますか？

現在、Oracle Enterprise Linux 3.8UEKの1つを使用しています。

この状況の回避策はありますか？ AWSではインスタンスを再作成するのは簡単ですが、ローカル開発環境では、dockerのために/ varパーティションがdevice-mapperによって90％所有されていることに気付くのは良くありません。 すぐにログやジャーナルのためのスペースがなくなります

上記の@ donrudo-最新のcentos6-504.3.3カーネルに更新します。

CentOSの場合は問題ありませんが、一部の開発者はFedoraを使用しており、その他の開発者はOpenSuseを使用しています。

すべてのDMシンプロビジョニングの変更は、最初にアップストリームに送信されます。 したがって、Centos 6が修正されると、アップストリームでも修正されます。 さまざまなディストリビューションは、修正をプルバックするか、より積極的にリベースする必要があります。

@ripienaarもう一度お聞きしますが、修正に必要なカーネルコミット（またはコミットのセット）を知っていますか？

@lexinator nope

この問題は、Ubuntu 14.04Trustyおよびカーネル3.13.0-36-genericで発生しています。 考えられる解決策は、AWS EBSストレージをディレクトリにアタッチして、無期限に拡張できるようにすることです。

みんな、この問題は本当に痛い。 CoreOSは現在ext4に移行しており、まもなくCoreOSでもこのような問題が発生するでしょう。

この問題が1年以上修正されていないときに、Dockerを（devまたはprodで）使用するにはどうすればよいですか？ 誰もが無限のディスクを持っていますか？

私は彼らがdevmapperではなくオーバーレイのためにext4に移行していると信じています。 しかし、それは
通りの言葉だけ...

2015年1月28日水曜日、Sergeynotifications @ github.comは次のように書いています。

みんな、この問題は本当に痛い。 CoreOSは現在ext4に移行しており、間もなく
CoreOSでもこのような問題が発生します。

この問題が修正されていないときに、Dockerを（devまたはprodで）使用する方法
一年以上？ 誰もが無限のディスクを持っていますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/3182#issuecomment-7180​​0923 。

私は混乱しています。 Googleインスタンスのディスク容量はわずか10Gですが、/ var / lib / docker / devicemapper / devicemapper / dataのサイズは100Gと表示されます。 すべてのコンテナとイメージを削除した後でも、スペースを再利用できません。

それはスパースファイルです。 使用ls -shの代わりにls -l 、または交互に、 du -h

私はこれをUbuntu13.04で報告できます（おそらく驚くことではありません）。

現在、デバイスマッパーの成長を予測するのに十分なディスク容量をプロビジョニングするための唯一の実際の回避策はありますか？

このスレッド全体は非常にばかげています。 次々と不平を言うDebianユーザー。 問題が発生した場合は、適切に保守されているディストリビューションに切り替えるか、ディストリビューションの保守担当者と協力して問題を修正してもらう必要があります。 これらのディストリビューションは、修正や改善に追いついていない。 修正がすでに明らかに上流にあることを考えると、ディストリビューション$ fooでこの問題を修正するよう誰かに懇願する将来のすべてを無視します（CentOSまたはRHELを参照）。 問題の壊れたディストリビューションに対するバグを開いて、この問題を参照してください。

Dockerが次のプラットフォームでサポートを維持している場合、それほどばかげたことではありません。

Docker is supported on the following versions of Ubuntu:

Ubuntu Trusty 14.04 (LTS) (64-bit)
Ubuntu Precise 12.04 (LTS) (64-bit)
Ubuntu Raring 13.04 and Saucy 13.10 (64 bit)

この問題が明らかに非常に蔓延している場合、どうすれば14.04の包括的なサポートコールを利用できますか。 Dockerは明らかに、特定のディストリビューションの特定のカーネルに対する包括的なサポートを終了する必要があります。

私はCentOSを使用していますが、カーネルのアップグレードにより、デバイスマッパーの暴走の問題が改善されたようです。

とにかく、@ snitmの作業に感謝します。

Ubuntuでこの問題が発生している場合は、古いDockerイメージ/コンテナーを適切にクリーンアップしていることを確認してください。 クリーンアップスクリプトが実行されていると思ったときに実行されていなかったことがわかりました。そのため、多くのスペースを使用していました。

`` `＃！/ bin / bash

すべてのコンテナを削除します

docker rm $（docker ps -a -q）

すべての画像を削除する

docker rmi $（docker images -q）
`` `

@TylerMillsは、 docker rmがコンテナによって作成されたボリュームを削除しないことに注意してください。 コンテナーがボリュームを使用する場合は、 docker rm -vを使用して、Dockerにボリュームも削除させる必要があります。

@snitmこれも少しだけです（Ubuntu 14.04を使用）。 特にDockerのせいではないかもしれませんが、全体的なエクスペリエンスにあまり反映されていないため、これを修正することに強い関心を持っているはずです。

また、私がこの問題にぶつかったことにも注意してください。これは私がそれを修正するためにしたことです。

ただし、私の場合、/ varが100％の使用率に達するとマウントされているため、ホストがカーネルパニックに陥るのを防ぐ唯一の方法は、dockerプロセスを直接強制終了することです（つまり、dockerコマンドを発行するとパニックになります）。

次に、次のコマンドを使用して、devicemapperマウントを使用してプロセスを手動で強制終了します。

grep docker /proc/*/mounts | awk -F/ '{ print $3 }' | xargs kill -9

次に、以下を使用してデバイスマッパーマウントをアンマウントできました。

for i in /dev/mapper/docker-*; do umount $i; dmsetup remove $i; done

これらの手順により、すべてのファイル記述子が解放され、スペースを再利用したり、ファイルを削除したりできるようになりました。

私の場合、その時点で、/ var / lib / dockerディレクトリをより多くのスペースのあるマウントに移動し、 -g引数を使用して別のホームディレクトリを使用するようにdockerデーモンを構成する方が理にかなっています。

AdamMiller経由のAlexanderLarssonに感謝します

@dekzのコメントに続いて、インストールガイドが、 https ： 。

@JohnMoralesに感謝します。 Dockerからこれについて少し警告するのは素晴らしい考えです。

+1

+1

私たちは最近、Ubuntu 14.04.2 LTS（3.16.0-30-generic）を実行していることに少し気づきましたが、まだ解決策を探しています。 CentOS 6.6（おそらくカーネルが修正されている）に切り替えるか、より大きなディスクを備えたボリュームをマウントすることが唯一の解決策のようです。

Ubuntuを実行している人は、許容できる回避策を見つけましたか？

私は同意します-Dockerはこの問題に対処する必要があります-これはドキュメントと警告メッセージを必要とする深刻なバグなので、より多くの人が同じ罠に陥ることはありません。

@nateaに同意します
私はredhat6.5で同じ問題に直面しており、dockerが本番環境に対応していて、代替手段を探し始めているかどうかに大きな疑問符が付けられています。
この問題を解決するために手動で回避策を講じてもかまいませんが、現時点では、実行可能な回避策を認識していません。

@sagiegurarieは、6.5（および関連するカーネル）のさまざまな問題のために、CentOSの要件を6.6に

だから問題＃11643の答えは関係ありませんか？ つまり、redhat 6.5を使用できないということですか？

@natea @sagiegurari私たちのために働くのは、 @ TylerMillsによって提案された手動の「修正」

# Delete all containers
docker rm $(docker ps -a -q)
# Delete all images
docker rmi $(docker images -q)

もちろん、欠点は、すべてのイメージを再プルして、コンテナーを再度実行する必要があることです。

@bkeroackdsc以前にもすべてのコンテナとイメージを削除したのを覚えていますが、それでも解決しませんでしたが、

こんにちは！ この問題がubuntu-15.04にまだ存在するかどうか知りたいのですが。 これは現在linux-3.19カーネルにあります。 どうもありがとう。

あなたがそのカーネルでubuntu-15.05を使用しているなら、なぜオーバーレイを使用しないのか、それは方法です
devicemapperよりも優れています

木曜、11：26 AMで2015年5月7日、上Dreamcat4 [email protected]は書きました：

こんにちは！ この問題がubuntu-15.04にまだ存在するかどうか知りたいのですが。
これは現在linux-3.19カーネルにあります。 どうもありがとう。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/3182#issuecomment-99968299 。

@jfrazelleそうそう。 それはどんな感じ？ オーバーレイを使用していますか？ 私は（これまで）オーバーレイのサポートは3.19カーネルの時点でまだ実験的であるという仮定の下にありました。

はい私はオーバーレイを使用します:)私たちは1.7でリストの上位に移動したいと思っています
それを使用し、それを愛する

2015年5月7日（木曜日）に、Dreamcat4 [email protected]は書きました：

@jfrazellehttps ： //github.com/jfrazelleそうですね。 それはどんな感じ？ 行う
オーバーレイを使用しますか？ 私は（今まで）その仮定の下で行ってきました
オーバーレイのサポートは、3.19カーネルの時点ではまだ実験段階でした。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/3182#issuecomment-99982543 。

@sagiegurariなぜ6.5を

@jperrinそれは私の決定ではないので:)
とにかく、私はすべてのチームに、redhat7が本番環境で問題ないかどうかを確認しようとしています。

これは、CentOS7（3.10.0-123.el7.x86_64）ではまだ問題のようです。 新しいCentOSボックスをセットアップし、dockerv1.6.0をインストールしました。 devicemapperデータファイルは、sudo dockerrmiの後でサイズが減少することはありません。 CentOS6.6ボックスを入手して試してみる予定です。

Ubuntu 14.04のv1.6.0にはプラスの効果があるようです（v1.5.0より）

CentOS7でもうまく機能するようです。これはredhat7でも言えると思います。
しかし、redhat 6.5はそうではなく、ドキュメントでそれを述べることをお勧めします。

これは、最新のアップストリームDockerで機能するはずです。 そして@sagiegurariからの最後のコメントは

その場合は、このバグを閉じる必要があります。

それで、この問題は最新のDockerでもまだ発生していますか？ そうでない場合は、閉じましょう。

まあ....より多くのテストを実行すると、不確実な結果が得られるようです。
それははるかに良いと言えますが、それでもリークしている可能性があり、はるかに遅いです。
確認のためにさらにチェックを実行します。

@sagiegurari

あなたが直面している問題とあなたの環境についてもう少し詳しく教えてください。 問題のタイトルは、イメージ/コンテナーの削除時にスペースが再利用されないことを示しており、最新のアップストリームDockerにはそのような問題はないはずです。

アップストリームのDockerを取得し、動的バイナリを構築し、新しいシンプール（新しい/ var / lib / docker /内）を作成し、イメージをプルして削除し、Docker情報を確認して、スペースが解放されているかどうかを確認してください。そうではありません。

より正確な情報を提供するために、来週はさらに多くのテストを実行する予定です。

ビルドマシンでそれを確認し、（ビルド自体の間に）多くのイメージを作成および削除します+ dockerレジストリ2.0を実行します（常にタグ「latest」で異なるイメージをプッシュします）+いくつかのコンテナーを実行しますすべてが正常に機能することを確認する初期テストを実行します（テストは実際にはそのマシンで実行されることは想定されていませんが、初期段階にあるため、多数のコンテナーを作成/停止/実行します）。

私たちの画像は本当に大きく、仮想サイズが2GBを超えることもあるので、問題が発生した場合は、通常400mg前後の通常の画像よりも速く表示されます。

とにかく、私は動作を確認し、来週より多くの詳細を提供するためにいくつかのテストを実行しようとします。

Dockerバージョン1.6.0を使用して、Linuxカーネル3.14.35-28.38.amzn1.x86_64で4749651 /1.6.0をビルドします。

イメージを削除すると、dockerが要求するディスク容量が減少します。

@vbatts

この問題を解決できますか？最新のDockerでは、oopファイルからイメージ/コンテナースペースを再利用するという問題はないと思います。 特定の問題が発生した場合は、特定の詳細を含む新しい問題を開くことができます。

@rhvgoyal非常に多くの人々が非常に多くのプラットフォーム/バージョンについて不平を言った後、私はこの問題を急いで閉じる理由がわかりません。

@sagiegurari

問題をオープンにしておくことで何が得られるのかわかりません。 私はそれが上流で修正されていることを知っています。 未解決の問題はたくさんあります。 人々はそれらをダッシュ​​ボードとして使用して、観察結果を記録しています。

問題を開いたままにしておくことは、実際に再現可能な問題がある場合にのみ意味があると思います。 そうでなければ、この問題のリストは増え続け、どれに焦点を当てるべきかを判断するのは困難です。

あなたがそれを持ったら、誰もあなたがこの問題にさらにデータを追加するのを止めません。

@rhvgoyal最新のアップストリームでどのタグを参照していますか？

@rhvgoyal最新のコミットを言います。 最新のgitツリーのクローンを作成してテストします。 それは本当に重要ですか？

古いdockerリリースと古いカーネルで非常に多くの問題が報告されています。 最初のステップは、同じ問題が最新のDockerと比較的新しいkernerlで表示されるかどうかを確認することだと思います。 それがまだ問題なのか、それとも古いバージョンでは修正されていないものなのかがわかります。

誰かが戻ってきて、将来それを読むとき、そうです。 修正されたバージョンを知りたいと思っていました。

ループバックデバイスの場合は破棄を発行します。 それは実際にはずっと昔に行われました。 1.6にはあるべきだと思います。

@stanislavbは1.6でテストし、それは彼のために働きました。

この号の最初のコメントを参照すると、centos7でv1.6.0も試したが、まだ問題が発生していることがわかります。

@alexDrinkwater

わかりました、それを再現できますか？ どのような種類のシンプールを使用しましたか（ループデバイスの上に？）。 dockerを再起動しましたか、それともdockerを初めて起動したときに発生しますか？

場合によっては、dockerがループデバイスを使用してからdockerが再起動されることがあります。一部のデバイスがどこかでビジーであったために、プールがシャットダウンされなかった可能性があります。 Dockerを再起動すると
すでにそこにあるプールを検出し、ループバックデバイスが使用されていることを認識せず、破棄を発行しません。 あなたがその状況に出くわしたのだろうか？

CentOS 7

Dockerバージョン1.6.2.el7、ビルドc3ca5bb / 1.6.2

画像のクリーンアップ前

[root<strong i="8">@b2</strong> ~]# docker info
Containers: 1
Images: 320
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 10.74 GB
 Data Space Total: 107.4 GB
 Data Space Available: 96.63 GB
 Metadata Space Used: 22.8 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.125 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="11">@b2</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      483443064 13100584 470342480   3% /

いくつかのdockerrmiの後

[root<strong i="15">@b2</strong> ~]# docker info
Containers: 1
Images: 143
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 7.215 GB
 Data Space Total: 107.4 GB
 Data Space Available: 100.2 GB
 Metadata Space Used: 14.68 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.133 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="18">@b2</strong> ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      483443064 9665924 473777140   2% /

@alexDrinkwater

さて、ちょうど今、centos7イメージを起動してdocker 1.6を試しましたが、問題は見られません。 手順は次のとおりです。

[ root @ centos7-generic〜 ]
クライアントバージョン：1.6.0
クライアントAPIバージョン：1.18
Goバージョン（クライアント）：go1.4.2
Gitコミット（クライアント）：8aae715 / 1.6.0
OS / Arch（クライアント）：linux / amd64
サーバーバージョン：1.6.0
サーバーAPIバージョン：1.18
Goバージョン（サーバー）：go1.4.2
Gitコミット（サーバー）：8aae715 / 1.6.0
OS / Arch（サーバー）：linux / amd64

インポートされた画像はすでに1つあります。

[ root @ centos7-generic〜 ]
リポジトリタグ画像ID作成された仮想サイズ
docker.io/fedora最新のded7cd95e0592週間前186.5MB

Docker情報の出力は次のとおりです。

root @ centos7-generic〜 ]
コンテナ：0
画像：2
ストレージドライバー：devicemapper
プール名：docker-253：1-50331788-pool
プールのブロックサイズ：65.54 kB
バッキングファイルシステム：xfs
データファイル：/ dev / loop0
メタデータファイル：/ dev / loop1
使用されるデータスペース：525.5 MB
データスペースの合計：107.4 GB
使用可能なデータスペース：20 GB
使用されるメタデータスペース：892.9 kB
メタデータスペースの合計：2.147 GB
利用可能なメタデータスペース：2.147 GB
サポートされているUdev同期：true
データループファイル：/ var / lib / docker / devicemapper / devicemapper / data
メタデータループファイル：/ var / lib / docker / devicemapper / devicemapper / metadata
ライブラリバージョン：1.02.93-RHEL7（2015-01-28）
実行ドライバー：ネイティブ-0.2
カーネルバージョン：3.10.0-229.el7.x86_64
オペレーティングシステム：CentOS Linux 7（コア）
CPU：2

[ root @ centos7-generic〜 ] fedora
タグなし： fedora：最新
削除済み：ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
削除：48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic〜 ]
コンテナ：0
画像：0
ストレージドライバー：devicemapper
プール名：docker-253：1-50331788-pool
プールのブロックサイズ：65.54 kB
バッキングファイルシステム：xfs
データファイル：/ dev / loop0
メタデータファイル：/ dev / loop1
使用されるデータスペース：307.2 MB
データスペースの合計：107.4 GB
使用可能なデータスペース：20.22 GB
使用されるメタデータスペース：733.2 kB
メタデータスペースの合計：2.147 GB
利用可能なメタデータスペース：2.147 GB
サポートされているUdev同期：true
データループファイル：/ var / lib / docker / devicemapper / devicemapper / data
メタデータループファイル：/ var / lib / docker / devicemapper / devicemapper / metadata
ライブラリバージョン：1.02.93-RHEL7（2015-01-28）
実行ドライバー：ネイティブ-0.2
カーネルバージョン：3.10.0-229.el7.x86_64
オペレーティングシステム：CentOS Linux 7（コア）
CPU：2

通知データ使用量が525MBから307MBに減少しました。 したがって、画像を削除すると、スペースが元に戻りました。

さて、操作の前後にループファイルのサイズを貼り付けるのを忘れました。 ここにあります。

• 画像をプルする前。
  $ cd / var / lib / docker / devicemapper / devicemapper
  $ du-hデータ
  293Mデータ
• イメージプル後
  [ root @ centos7-generic devicemapper ]
  499Mデータ
• 画像削除後
  [ root @ centos7-generic devicemapper ]
  293Mデータ

そのため、画像の削除後にループファイルが実際に縮小しました。 それがあなたが不満を言っていることだと思います。

@stanislavb

ループファイルを使用していますか？ Docker情報には表示されません。 Dockerを開始したときにプールがすでに存在していたのと同じ問題が発生していると思います。

ループバッキングファイル（/ var / lib / docker / devicemapper / devicemapper / data）のサイズをチェックし、イメージの削除後にファイルが縮小することを確認できますか？ （du -h）。

@rhvgoyal
CentOS 7、Dockerバージョン1.6.2.el7、ビルドc3ca5bb / 1.6.2

[root<strong i="7">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
7041272 /var/lib/docker/devicemapper/devicemapper/data
[root<strong i="8">@b2</strong> ~]# docker rmi $(docker images -q)
...
[root<strong i="9">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
5617292 /var/lib/docker/devicemapper/devicemapper/data

@stanislavb

さて、ループデバイスのサイズは確かに小さくなっています。

また、コードから確認しました。 再起動時にdockerがすでにそこにシンプールを見つけた場合でも、破棄を発行します。

    // By default, don't do blk discard hack on raw devices, its rarely useful and is expensive
    if !foundBlkDiscard && (devices.dataDevice != "" || devices.thinPoolDevice != "") {
            devices.doBlkDiscard = false
    }

上記のコードに従って、ユーザーがデータブロックデバイスまたはシンプールを渡した場合にのみ、破棄が無効になります。 どちらも合格しなかったことを考えると、破棄はまだ続いています。 それがあなたのために働いている理由です。

@alexDrinkwaterこれで、1.6で修正された2つのデータポイントができました。 この問題を解決することにまだ懸念がありますか。

CentOS 6.6

Dockerバージョン1.5.0、ビルドa8a31ef / 1.5.0

画像のクリーンアップ前

[root<strong i="8">@b1</strong> ~]# docker info
Containers: 2
Images: 2996
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 43.24 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 117.1 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="11">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 53995488 397777856  12% /

残り1929枚のデータファイルのサイズを確認

[root<strong i="15">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
30G /var/lib/docker/devicemapper/devicemapper/data

いくつかのdockerrmiの後

[root<strong i="19">@b1</strong> ~]# docker info
Containers: 2
Images: 497
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 13.39 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 27.87 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="22">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 25606060 426167284   6% /
[root<strong i="23">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
13G /var/lib/docker/devicemapper/devicemapper/data

さて、1.5でも動作します。

これを新しいマシンでテストしました。

Dockerバージョン1.6.0、ビルド8aae715 / 1.6.0

引っ張る前：

/dev/mapper/os-var                             3.9G  750M  2.9G  21% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.308 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

引っ張った後：

/dev/mapper/os-var                             3.9G  815M  2.9G  23% /var

Containers: 0
Images: 22
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 639.9 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 1.438 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

画像を削除：

sudo docker rmi 617ef0e7677f
Untagged: docker.io/ghost:latest
Deleted: 617ef0e7677fbff322b8f3af29b9795314a333876d66b49e1ddede15229dccea
Deleted: e68d1ee297168a0b3c3e21ff7a9ab14f7df8edf4525e008fcaf3abc83c731387
Deleted: 4eee85e0d29b6836d3d46ff3b84b0292626df5c8428da0aeeb916d33b6fb7642
Deleted: d0e1169bd5617096df1776902e191f23c07ac0fb5b365c5664fd3d4a554e4c8e
Deleted: e983dda26a2392947fffa4cc37b36251b84bbc74c95ce9c353b80a9c8e63d70f
Deleted: 64b0f4c09fde536675106331c31636f8478ed0cf5c2c7aa274d464216e470b3f
Deleted: c0313e19f503a4770c00250049419a014972ba8f3458524d61b377b8fd289ef0
Deleted: ff1093062f402021a7574b3c40692d2c6dc7aec07d66e17caa6c35df19bad091
Deleted: 37b39063e0c0f3c1a8c90d304ad7ba6b47e14242ff60f6f5d091b280258e0ff3
Deleted: 6e878a0c2422a5496d6bfc5eaf1facbc48f66a8e437fdd7db18d8944b20f7072
Deleted: a10b93053713fb726beaea993bad52b39ca92c5ce6b646dbc7d9cd96016ee9bc
Deleted: 1324d506b72f2a602a8f55c5224708e8ff02dec86b5fe46462a1d73aafb32075
Deleted: 70014f2a472b03d0cfde21d99c601db25f62de1d6c8497cadd6e05743c09d5a1
Deleted: f81216b6a47e2f51c80ff56044a5120d4b8cb76e9ea5990ba08ed073e97fd429
Deleted: 286e04b15dcfe587da0d8b6b359d6ae74c3ef299b868183859508304153ceaca
Deleted: 1dbb5edeebca3ae23a32fcf600015df645a788747553287548ce67126b206ab7
Deleted: 8807133d30b36044c670a06b087b6b61082b660a61fef651f0871283c5505bff
Deleted: 4c0283973ca2335a9ae82168956e4add2e6f2f13fd31e16473d695912e34d974
Deleted: 95d6d696e46933c9d063b5d6328b1a92b988462f1277d74d42bbbdd568efc220
Deleted: 80565b90e8eb693f03cea0411aadb45f21f2bcfe39f6b0fda8cf351eaee1f81b
Deleted: df2a0347c9d081fa05ecb83669dcae5830c67b0676a6d6358218e55d8a45969c
Deleted: 39bb80489af75406073b5364c9c326134015140e1f7976a370a8bd446889e6f8

削除後：

/dev/mapper/os-var                             3.9G  814M  2.9G  23% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

私のマシンやバージョンなどの詳細があれば教えてください。

@alexDrinkwater

/ varに別のデバイスをマウントしているようです。 そのデバイスのファイルシステムとマウントオプションは何ですか？

また、私に以下を教えてもらえますか。

• dmsetupテーブル
• dmsetupステータス
• cat / etc / sysconfig / docker-storage

xfsファイルシステムを使用してルート自体に/ varを保持するというより単純なケースを試すことができますか？ 問題を少し絞り込もうとしています。

@alexDrinkwater

/ var / lib / dockerにext4パーティションを持つ別のディスクをマウントして、ループバックバッキングファイルが（xfsではなく）ext4にあるようにしましたが、それでも問題はありません。

/ var / lib / dockerタイプext4の/ dev / vdb1（rw、relatime、seclabel、data = ordered）

セットアップの何が特別なのか本当にわかりません。

具体的には、

• 引っ張る前に
  / dev / vdb1 9.8G 338M 8.9G 4％/ var / lib / docker
• イメージプル後
  / dev / vdb1 9.8G 544M 8.7G 6％/ var / lib / docker
• 画像削除後
  / dev / vdb1 9.8G 338M 8.9G 4％/ var / lib / docker

@alexDrinkwater

あなたのセットアップと私のセットアップのもう一つの大きな違いはカーネルバージョンです。 「3.10.0-123.el7.x86_64」を使用しているようですが、「3.10.0-229.el7.x86_64」を使用しています。 カーネルをアップグレードして試してみてください。

@rhvgoyalの助けをありがとう。 今日はカーネルを更新できません。 しかし、ここにあなたが求めた設定があります：

/dev/mapper/os-var /var ext3 rw,relatime,data=ordered 0 0

vgdocker-lvdocker: 0 62906368 linear 8:17 2048
os-tmp: 0 8388608 linear 8:2 5244928
os-var: 0 8388608 linear 8:2 13633536
os-swap: 0 5242880 linear 8:2 2048
os-root: 0 8388608 linear 8:2 22022144
docker-253:3-247472-pool: 0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing 

vgdocker-lvdocker: 0 62906368 linear 
os-tmp: 0 8388608 linear 
os-var: 0 8388608 linear 
os-swap: 0 5242880 linear 
os-root: 0 8388608 linear 
docker-253:3-247472-pool: 0 209715200 thin-pool 79 179/524288 4688/1638400 - rw discard_passdown queue_if_no_space 

DOCKER_STORAGE_OPTIONS=

カスタムストレージオプションを構成していません。

それを見つけた。 ext3ファイルシステムと関係があると思います。 私も問題を見ることができます。 ext4やxfsなどの別のファイルシステムを試してみてください。問題は発生しません。

/ var / lib / dockerタイプext3の/ dev / vdb1（rw、relatime、seclabel、data = ordered）

• 画像をプルする前
  [ root @ centos7-generic-2 devicemapper ]
  293Mデータ
• 画像をプルした後
  [ root @ centos7-generic-2 devicemapper ]
  501Mデータ
• 画像削除後
  [ root @ centos7-generic-2 devicemapper ]
  501Mデータ

したがって、何らかの理由でループバックファイルがext3ファイルシステム上にある場合、それは機能しません。 ext3は十分に古いため、ループ破棄が機能しない可能性があります。

おかげで、ファイルシステムがext3であるのを見るとすぐに、それでいいのではないかと思いました。 ext3で問題を再現できれば、この問題は解決したと言えます。 それは他の人にとって良い参考になるでしょう。

参考までに、私の作業例はxfsファイルシステムのDocker 1.6.2と、ext4のDocker1.6.0および1.5.0でした。

@vbatts

これを閉じてもいいですか。 スペースの再利用は、xfsとext4で問題なく機能します。 ext3は古すぎてサポートできないようです。

@rhvgoyal @vbatts IIRC、基盤となるファイルシステムをチェックする互換性チェックがあります。 ここで問題が発生した場合は、おそらくext3チェックを追加する必要がありますか？

編集：
参考のため; デーモン/グラフドライバー/オーバーレイ/オーバーレイ.go＃L115

ループドライバは、破棄が入ったときにfallocate（）を使用してファイルに穴を開けます。fallocate（）のLinux manページは、ext3でサポートされていないことを確認します。

/ *
すべてのファイルシステムがFALLOC_FL_PUNCH_HOLEをサポートしているわけではありません。 ファイルシステムが操作をサポートしていない場合、エラーが返されます。 この操作は、少なくとも次のファイルシステムでサポートされています。
* XFS（Linux 2.6.38以降）
* ext4（Linux 3.0以降）
* Btrfs（Linux 3.7以降）
* tmpfs（Linux 3.5以降）
* /

@thaJeztah

誰かがext3でdockerを実行したい場合は、それを許可する必要があると思います。 破棄のサポートが得られないため、イメージ/コンテナが削除されてもループファイルのサイズは縮小されません。

@rhvgoyalこれをdocker infoどうですか？ Udev Sync Supported出力に似ています。

@thaJeztah

Docker情報「Backingfilesystem」にすでにエントリがあります。 ext2 / ext3 / ext4について正確ではなく、なぜextfsと表示されるのかわかりません。

ログの起動時に警告が表示される場合があります。 シンプールにループデバイスを使用することについての警告に似たもの。

@thaJeztah

そして、多くの人がこれに影響を受けた場合にのみ、それを行うべきだと思います。 そうでない場合は、より多くの作業とコードを作成しているだけであり、それだけの価値はないかもしれません。

syscall.Statfs_t構造体、ext2、ext3、およびext4のTypeフィールドはすべて、 0xef53返します。これは、ファイルシステムの魔法を検出するために使用しているものです。

ext2、ext3、およびext4のTypeフィールドを持つsyscall.Statfs_t構造体は、すべて0xef53を返します。これは、ファイルシステムの魔法を検出するために使用しているものです。

バマー。 報告された問題を簡単に特定できるように、その情報があればよかったのにと思います。

じゃあ、これを閉じればいいのかな？

これはext3が古くなっている問題であるため、終了します。 ext4またはxfsを使用してください

どういうわけか、これはメインのDockerドキュメントでより適切に文書化できると思いますか？

問題がファイルシステムにあるかどうかにかかわらず、これが最近の2つの問題でどれほどの混乱を引き起こしているかを見てください。

ありがとう。

＃9786の発行を控える

@dbabitsはい、ext3にいくつかの問題があることを言及することは、ドキュメントで言及する価値があると思います。 適切な場所が何であるかはまだわかりません。

XFSで同じ/同様の問題があります。
カーネル「3.10.0-123.el7.x86_64」にありましたが、「3.10.0-229.el7.x86_64」で更新されました。

すべてが削除されますが（コンテナー、イメージ）、データには100GBが含まれています。
何かアイデアはありますか？

[ root @ docker0101〜 ] ＃ls -alh / data / docker / devicemapper / devicemapper /
合計80G
drwx ------ 2ルートルート326月8日16:48。
drwx ------ 5ルートルート506月9日07:16 ..
-rw ------- 1ルートルート100G 7月16日21:33データ
-rw ------- 1ルートルート2.0G 7月17日09:20メタデータ

[ root @ docker0101〜 ]
Linux docker0101 3.10.0-229.7.2.el7.x86_64＃1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101〜 ]
CentOS Linuxリリース7.1.1503（コア）

[ root @ docker0101〜 ]
コンテナIDイメージコマンドが作成したステータスポート名

[ root @ docker0101〜 ]
リポジトリタグ画像ID作成された仮想サイズ

[ root @ docker0101〜 ]
コンテナ：0
画像：0
ストレージドライバー：devicemapper
プール名：docker-253：0-268599424-pool
プールのブロックサイズ：65.54 kB
バッキングファイルシステム：xfs
データファイル：/ dev / loop0
メタデータファイル：/ dev / loop1
使用されるデータスペース：85.61 GB
データスペースの合計：107.4 GB
使用可能なデータスペース：40.91 MB
使用されるメタデータスペース：211.4 MB
メタデータスペースの合計：2.147 GB
利用可能なメタデータスペース：40.91 MB
サポートされているUdev同期：true
データループファイル：/ data / docker / devicemapper / devicemapper / data
メタデータループファイル：/ data / docker / devicemapper / devicemapper / metadata
ライブラリバージョン：1.02.93-RHEL7（2015-01-28）
実行ドライバー：ネイティブ-0.2
カーネルバージョン：3.10.0-229.7.2.el7.x86_64
オペレーティングシステム：CentOS Linux 7（コア）
CPU：4
総メモリ：11.58 GiB
名前：docker0101

[ root @ docker0101〜 ]
vg1-lvol0：0167772160線形8：162048
docker-253：0-268599424-pool：0 209715200 thin-pool 7：1 7：0 128 32768 1 skip_block_zeroing

[ root @ docker0101〜 ]
vg1-lvol0：0167772160線形
docker-253：0-268599424-pool：0 209715200 thin-pool 71359 51606/524288 1306264/1638400 --ro Discard_passdown queue_if_no_space

[ root @ docker0101〜 ]
DOCKER_STORAGE_OPTIONS =

[ root @ docker0101〜 ] docker
名前：docker
バージョン：1.6.2
リリース：14.el7.centos
アーキテクチャ：x86_64
インストール日：2015年7月17日金曜日09:19:54 CEST
グループ：詳細不明
サイズ：33825026
ライセンス：ASL 2.0
署名：RSA / SHA256、2015年6月24日水曜日05:43:12 AM CEST、キーID 24c6a8a7f4a80eb5
ソースRPM：docker-1.6.2-14.el7.centos.src.rpm
ビルド日：2015年6月24日水曜日03:52:32 AM CEST
ビルドホスト：worker1.bsys.centos.org

[root @ docker0101〜 ]
lrwxrwxrwx1ルートルート12Jun 9 08:21 / var / lib / docker-> / data / docker

[ root @ docker0101〜 ]＃マウント
/ varタイプxfsの/ dev / sda5（rw、relatime、attr2、inode64、noquota）
/ data typexfs（rw、relatime、attr2、inode64、noquota）の/ dev / mapper / vg1-lvol0

@tomlux使用しているdevicemapperループバックモードは、主にhttp://www.projectatomic.io/docs/docker-storage-recommendation/を読むことを強くお勧めし

すべてのシステムアップデートを適用したと仮定すると、パフォーマンスが向上し、このような問題は発生しません。

@tomlux

lsに「-s」を追加できますか。 これにより、データファイルとメタデータファイルに割り当てられた実際のブロックが得られます。 現在、ファイルの見かけのサイズが表示されています。

Docker情報の出力は興味深いものです。 使用率が高いようです。

@tomlux

そのため、データとメタデータファイルの実際のサイズは小さく見えます。 サイズを読みやすくするために、「ls-alsh」を使用できます。

したがって、データファイルのサイズは約79MB、メタデータファイルのサイズは約202KBのようです。

どういうわけか、使用されたブロックの数に関するシンプールの統計は正しく見えないと思います。 マシンを再起動すると問題は解決しますか？

カーネルの更新後に再起動しましたが、成功しませんでした。

さて、ループファイルは大きく、プールは使用済みブロックがたくさんあると考えています。 したがって、何かがそれらのブロックを使用しています。 の出力を教えていただけますか。

• docker ps -a
• Docker画像
• ls / var / lib / dokcer / devicemapper / metadata / | wc -l
• Dockerをシャットダウンし、以下を実行します。
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "device dev_id" | wc -l

これにより、プール内にシンデバイスがいくつあるかがわかります。

うーん、
現在、DEADコンテナがありますが、画像はありません。
すでに再起動しました。

デバイスマッパーに問題があるようです。
この問題をスパムしたくありません。
「rm-f / var / lib / docker」を実行して、コンテナーを再構築することもできます。 すべてがスクリプト化されています。

「dmsetupstatus」を実行します

プールの状態が悪いようで、おそらく修理が必要です。

こんにちは、

Ubuntu14.04でも同じ問題が発生しているようです。 ただし、不要なボリュームが発生する原因（ブログhttp://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/を参照）。 コマンドの実行

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes

多くのディスク容量を解放しました。

これは意味のある方法で修正されていません。 完全に最新のUbuntu14.04.xインストール（最新のLTSリリース）および最新バージョンのDocker（ $ wget -qO- https://get.docker.com/ | sh経由でインストール）では、Dockerは継続的にスペースをリークし、簡単に再利用する方法はありません。 docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q)は、わずかなスペースしか解放しません。

すべてのスペースを再利用する唯一の方法は、次のハックを使用することです。

$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start

次に、必要になる可能性のある画像を再プルする必要があります。

@bkeroackdscそのスペースは、「孤立した」ボリュームにも関連している可能性がありますか？

@bkeroackdscに同意します。これは解決されていません。
私は@rhvgoyalに、なぜ彼がこのケースを
最後に、特にこの問題のために、Dockerからドロップしました。
それはこの製品を殺しています。

孤立しているか孤立していないかにかかわらず、スペースをクリーンアップするための適切で簡単な方法はありません。
この問題は多くのプラットフォームで非常に多くの人に発生するため、クリーンアップ用のdocker cliオプション、適切なステータスレポートcliオプション、およびディスクスペースの何らかの監視が必要です。

@bkeroackdsc @sagiegurari

私が尋ねている理由は、孤立したボリュームがこの問題に関連していないということです。
devicemapperとは関係あり

孤立したボリュームはバグではあり
コンテナの場合、コンテナが削除されると自動的に削除されます。
ボリュームにはデータを含めることができるため、これは（設計上）そうではありません。
これは、コンテナが削除された後も持続するはずです。

_コンテナと一緒にボリュームを削除するには_、 docker rm -v [mycontainer]ます。
ボリューム管理機能が追加されます（https://github.com/docker/docker/pull/14242およびhttps://github.com/docker/docker/issues/8363を参照）。
「孤立した」ボリュームを管理できるようになります。

/var/lib/dockerサイズが大きくなっていることを示す必要はありません
そのディレクトリのサイズが大きくなるため、そのデバイスマッパーはデータをリークしています
クリーンアップされていない（孤立した）ボリュームの結果である可能性もあります
ユーザーによる（dockerはすべてのデータをそのパスに格納します）。

これらの2つのアイテムが必要な機能を提供することを本当に望んでいます。
私は2番目の項目を理解しましたが、最初の項目（＃14242）は、ボリュームAPI（つまり、どの機能が提供されるかわからない）を除いて、それが何であるかを上部に説明していません。

@sagiegurariこれは、イメージボリューム管理を実装するための要件の一部です（他にもいくつかの未解決のPRの問題があります）。 最終的な目標は、ボリュームをDockerの第一級市民にすることです。これは、ボリュームを使用するコンテナーとは別に作成/削除/管理できます。

@swachterその回避策を投稿していただきありがとうございます、私は前述の画像で6GBを回収しました。

ダーティハックによるリークボリュームの問題を修正しました。これは、高チャーンのDockerホストでサービスがタイムアウトする前にDockerデーモンが起動するのを妨げていたためです。

PRODUCTION [[email protected] ~]$ cat /etc/systemd/system/docker.service.d/docker-high-churn.conf 
[Service]
ExecStartPre=-/bin/rm -rf /var/lib/docker/containers
ExecStopPost=-/bin/rm -rf /var/lib/docker/volumes

これにより、事前にキャッシュされた画像をフラッシュせずに問題が修正されます。

リークボリュームの問題については、別の問題で説明できますか。 ここで説明すると、デバイスマッパーの問題であるのに、そうではないという印象を与えます。

@tomlux @rhvgoyal

CentOS 7ボックスで何が起こっているのかについて結論を出したことはありますか？ 私のDockerホストはほぼ同じで、同じ問題が発生していました。 @rhvgoyalがthin_dumpコマンドの実行を要求するところまで続きました。 その後、dockerデーモンを起動しようとしましたが、起動しませんでした。 / var / lib / dockerを削除して再起動しましたが、解決策が見つかったかどうかを知りたいと思っていました。私（および他の人）が再び問題に遭遇する可能性があるためです。

[root<strong i="11">@Docker_Sandbox_00</strong> devicemapper]# thin_dump /var/lib/docker/devicemapper/devicemapper/metadata | grep "device dev_id" | wc -l
102

[root<strong i="14">@Docker_Sandbox_00</strong> devicemapper]# systemctl start docker
Job for docker.service failed. See 'systemctl status docker.service' and 'journalctl -xn' for details.
 [root<strong i="15">@Docker_Sandbox_00</strong> devicemapper]# systemctl -l status docker.service
docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
   Active: failed (Result: exit-code) since Tue 2015-10-27 08:24:47 PDT; 37s ago
     Docs: https://docs.docker.com
  Process: 45244 ExecStart=/usr/bin/docker daemon -H fd:// (code=exited, status=1/FAILURE)
 Main PID: 45244 (code=exited, status=1/FAILURE)

Oct 27 08:24:45 Docker_Sandbox_00 systemd[1]: Starting Docker Application Container Engine...
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.512617474-07:00" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526637164-07:00" level=info msg="Option DefaultDriver: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526719113-07:00" level=info msg="Option DefaultNetwork: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.589016574-07:00" level=warning msg="Running modprobe bridge nf_nat br_netfilter failed with message: modprobe: WARNING: Module br_netfilter not found.\n, error: exit status 1"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.625324632-07:00" level=info msg="Firewalld running: true"
Oct 27 08:24:47 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:47.142468904-07:00" level=fatal msg="Error starting daemon: Unable to open the database file: unable to open database file"
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Failed to start Docker Application Container Engine.
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Unit docker.service entered failed state.

[root<strong i="18">@Docker_Sandbox_00</strong> devicemapper]# df -ah
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vdb1                                    20G   20G   24K 100% /var/lib/docker
[root<strong i="19">@Docker_Sandbox_00</strong> devicemapper]# du -sh /var/lib/docker/devicemapper/devicemapper/data
20G     /var/lib/docker/devicemapper/devicemapper/data

@tomlux @rhvgoyal

問題の原因を見つけました。 それがどのように見えたかにもかかわらず、それはスレッドの問題とは無関係でした。 これは、Dockerがどのように機能するかについての誤解から生じたものです。 すべて、死んだコンテナは、実行中に割り当てたディスクスペースを保持していました。 ディスクスペースを解放するために、すべてのコンテナの死骸を取り除く必要がありました。 これがこのスレッドで発生したことを覚えていますが、コンテナによって割り当てられたディスクスペースではなく、マウントされたボリュームと見なされるだけだと思いました。

# Beware this removes ALL containers
docker rm -f $(docker ps -aq) 

@tomlux docker ps -a出力にいくつかのDeadコンテナが表示されたため、これも問題になっている可能性があります。

dockerrmがコンテナのディスクスペースを解放していません

OS XVirtualBoxの最近のboot2docker。 OSXに完全にパッチが適用されました。

ファット（47 GB）コンテナーを作成していますが、コンテナーを再構築する必要があることを示す問題があります。 そこで、コンテナーを停止して、dockerrmを実行しました。 dockersshを使用したダブルチェック'df -h'、ディスク使用量はまだ47GBです。 コンテナの容量は75GBです。

そのため、DockerVMを再度強制終了する必要があります。

これを成し遂げることができますか？

@ awolfe-silverskyは、VMの_内部_にディスクスペースが返されますか？ VMの外部にある場合、これは無関係である可能性があります。

@ awolfe-silverskyも; _image_も削除しましたか？ 画像がまだそこにある場合は、コンテナだけを削除してもあまり役に立たない場合があります

@ awolfe-silverskyこの問題はdevicemapperに関するものです-docker-machine / boot2dockerを使用している場合は、 aufs実行している可能性がはるかに高くなります。 また、あなたはあなたの大きなイメージをdocker rmi 'したのだろうか。

docker imagesとdocker infoを実行して、物事が本当に悲惨であるかどうかを確認する価値があります:)

（はい、まだvmがあり、イメージが削除されている場合は、奇妙なコーナーケースを見つけたので、新しい問題を開いてさらにデバッグする必要があります）

画像は削除しませんでした。 これは、内部のDockerレジストリからのものです。
私はawkスクリプトを使用して画像のサイズを設定しました-合計6.9GB。

docker images -a | awk '(FNR > 1) { imgSpace = imgSpace + $(NF - 1); }
END { print "Image space is " imgSpace; }'
Image space is 6909.01

汚れていますが、すべての画像サイズがMB単位であることはわかっています。

使用状況を診断しようとした方法は次のとおりです。

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10063: docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10064: docker-machine ssh 'awolfe-dbhost' 'df -h'
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.0G    123.8M      6.9G   2% /
tmpfs                     3.9G         0      3.9G   0% /dev/shm
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1
cgroup                    3.9G         0      3.9G   0% /sys/fs/cgroup
none                    464.8G    379.9G     84.8G  82% /Users
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1/var/lib/docker/aufs

現在、画像が0個のボックスがあります。
docker volume ls -qf dangling=trueは何も表示しません。
docker volume lsは多くのボリュームを示していますが、それらを所有するイメージがないため、定義上、孤立しています。
docker volume rm $(docker volume ls)は、そのようなメッセージをたくさん表示します。

Error response from daemon: get local: no such volume
Error response from daemon: Conflict: remove 6989acc79fd53d26e3d4668117a7cb6fbd2998e6214d5c4843ee9fceda66fb14: volume is in use - [77e0eddb05f2b53e22cca97aa8bdcd51620c94acd2020b04b779e485c7563c57]

デバイスマッパーディレクトリは30GiGを消費します。
Dockerバージョン1.10.2、ビルドc3959b1
CentOS 7、3.10.0-327.10.1.el7.x86_64

Data Space Used: 33.33 GB
 Data Space Total: 107.4 GB
 Data Space Available: 915.5 MB
 Metadata Space Used: 247 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 915.5 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)

また、デフォルトのインストールで「強く推奨されない」ストレージオプションを使用するのはなぜですか？
インストール時にそう言われなかったのはなぜですか？

Amazon LinuxEC2インスタンスでもまったく同じ問題が発生します。

Linux ip-172-31-25-154 4.4.5-15.26.amzn1.x86_64 #1 SMP Wed Mar 16 17:15:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

新しいDockerイメージを定期的にインストールする場合、唯一の解決策は次のことを行うことです。

service docker stop
yum remove docker -y
rm -rf /var/lib/docker
yum install docker -y
service docker start

実稼働環境ではそのようなことは受け入れられないと思います

いくつかの追加情報：

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   20G     0 100% /

このバグは何年も存在し、まだクローズされていないようですが、すべてのDocker情報の安全性を破壊する方法についてdevidemapperに関するDockerドキュメントを挿入できますか？
つまり、このページでは： https ：
「クリーニングデバイスマッパー」のようなものとその方法を入力してください。

rm -rf / var / lib / dockerを実行しようとしますが、それを実行するのは快適ではありません。 安全かどうか誰かに教えてもらえますか？

私は毎日のラップトップでgentoolinuxを使用しており、学習のためにdockerを試しましたが、ディスクがいっぱいになり、システム全体を再インストールすることはできません。VMではないため、gentooの再インストールには時間がかかります。

お疲れ様でした。

@mercuriete開発マシンで

@ ir-fuel：私はちょうどそれをしました、そして今私はこれを持っています：

$ sudo service docker-engine start
Redirecting to /bin/systemctl start  docker-engine.service
Failed to start docker-engine.service: Unit docker-engine.service failed to load: No such file or directory.
$ uname -a
Linux CentOS7 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

service docker start

@ ir-fuelありがとう、それはうまくいきます。 ：+1：

Dockerを再インストールしてディスク容量を解放することは、この問題の解決策を探しているときに出くわした最もばかげた答えです。 それは時間の無駄であるだけでなく、ほとんどの環境で許可されていません。 あなたが時間給労働者であるならば、それは支払いを受ける良い方法です。

同意します。 Dockerのような製品が、アンインストール/再インストール以外に何もできない状態でディスクスペースを使い果たし続けるのは驚くべきことです。

この問題をもう一度チェックインして、何も変更されていないことを確認します。 +1

この問題はクローズ済みとしてマークされています。 解決策が必要です。 回避策や再構成はありません。 実際のステータスとは何ですか？また、関係する構成設定は何ですか？ 本番Dockerノードを削除して再作成することはできません。

そして、代替手段は何ですか？ これを回避するにはどうすればよいですか？

これが推奨されない機能である場合-なぜそれはサイレントでデフォルトなのですか
1？ devicemapperを使用している人を気にしない場合-私も大丈夫かもしれません
これとともに。 しかし、それについてユーザーに知らせてください！ あなたはの量を理解していますか
あなたが落ち着いたこの驚くべき「回避策」のために人々が抱えている頭痛は??
2016年6月23日午後4時32分、「kpande」 [email protected]は次のように書いています。

回避策は、docker device-mapperdriverの使用を回避することです。
残念ながら。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/3182#issuecomment -228068397、またはミュート
スレッド
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
。

常にrktがあります…

一般的な愚かな役に立たないスナークは、上流の誰もあなたに適切な答えを与えようとしない理由は間違いありません。

Dockerの使用を強制された人はいません。

これは、JVMのバグのためにOracleがJava開発者にPHPを使用するように指示しているようなものです。 これもここのエレベーターピッチと一致していません

3年前、Dockerは、コンテナー化と呼ばれる難解なLinuxカーネルテクノロジーをシンプルで誰もが利用できるようにしました。

Dockerがそのように離陸したこと、そしてコミュニティからのボランティアなしでは実現できなかったことに、多くの人が感謝していると思います。 ただし、誰かが好ましくない点を指摘するたびに「私はアップストリームの貢献者なので、黙って聞いてください」という行を暗黙的に削除せずに、問題があることを認めるのはそれほど難しいことではありません。

待つ。 私は問題を報告し、私のマシンとセットアップの詳細を提供しました、
私は義務ではありません。 devteamの誰も私や他のバグに応答しませんでした
半年の期間で報告します。 今私はこの事実を述べました、あなたは私の行動を呼びます
ビッチ？ オープンソースもありますか？ 作業するGoプロジェクトを探しています。
それはDockerではありません、私はあなたにそれを与えます。 これがあなたの目標ですか？
2016年6月23日16:45、「 gregorygrey 」

これが推奨されない機能である場合-なぜそれはサイレントでデフォルトなのですか
1？ devicemapperを使用している人を気にしない場合-私も大丈夫かもしれません
これとともに。 しかし、それについてユーザーに知らせてください！ あなたはの量を理解していますか
あなたが落ち着いたこの驚くべき「回避策」のために人々が抱えている頭痛は??
2016年6月23日午後4時32分、「kpande」 [email protected]は次のように書いています。

回避策は、docker device-mapperdriverの使用を回避することです。
残念ながら。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/3182#issuecomment -228068397、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
。

まず、この問題がまだ発生する場合は、新しい問題を開いてください。

待つ。 問題を報告しました

あなたは3歳のクローズドイシューに返信しました。 上記の説明に続いて、元の問題は解決されました。 あなたの問題は同じかもしれませんが、確実にするためにもっと研究が必要です。 あなたが報告しているエラーは、それが実際には別のものである可能性があることを示しています。

クローズされた問題についてコメントするのではなく、新しい問題を開くことを強くお勧めします

私のマシンとセットアップの詳細を提供しましたが、私は義務付けられていません。

あなたは義務付けられていませんが、続行するための情報がなければ、解決される可能性はほとんどありません。 したがって、バグを報告するときは、テンプレートに要求された情報を含めてください。
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

半年の間に、devteamの誰も私や他のバグレポートに応答しませんでした。

「メンテナの一人」という意味では、24000近くの問題とPRがあり、20人未満のメンテナがいて、その多くが日常業務以外にそれを行っていることを覚えておいてください。 特にクローズドイシューの場合、すべてのコメントが通知されるわけではありません。

これが推奨されない機能である場合、なぜサイレントでデフォルトの機能なのですか？

_aufs _、_ btrfs_、および_zfs_がサポートされていない場合はデフォルトです。ドライバーを選択するときに使用される優先順位を見つけることができます。 デーモン/グラフドライバー/driver_linux.goを参照してください。 残念ながら、そのドライバーには_一部の_人が影響を受ける可能性のある問題がいくつか残っているため、まだオーバーレイの上にあります。

グラフドライバーを自動的に選択することは、単に「物事を実行する」ことです。 _your_状況に最適なドライバーは、_your_ユースケースによって異なります。 Dockerはその決定を自動的に行うことができないため、これはユーザーが構成する必要があります。

devicemapperを使用している人を気にしないのであれば、これでも大丈夫かもしれません。

上記の説明を読み返すと、アップストリームのデバイスマッパーのメンテナがこの_複数回_を調査し、ユーザーがこれらの問題を報告し、問題を解決するのを支援しようとしていることがわかります。 この問題は、それを報告した人、または場合によっては、デバイスマッパーのバージョンを更新するディストリビューションに依存していた人のために解決されました。 それは「気にしない」とは言えないと思います。

また、デフォルトのインストールで「強く推奨されない」ストレージオプションを使用するのはなぜですか？

Dockerを実行するには、ループデバイスで実行するのが適切であり、現在、devicemapperを自動的にセットアップする唯一の方法です。 本番環境で、全体的なパフォーマンスを向上させるには、ストレージドライバーユーザーガイドのdevicemapperセクションで説明されているように、direct-lvmを使用します。

インストール時にそう言われなかったのはなぜですか？

それは実際にはインストールの範囲外です。 本番環境でソフトウェアを使用する場合は、そのソフトウェアに精通し、ユースケースに合わせてソフトウェアをセットアップするために何が必要かを理解していると想定するのが妥当です。 一部のメンテナは、警告を出力する必要があるかどうかさえ主張しました。 Linuxは「手をつなぐ」OSではありません（RAID-0を使用している場合、データ損失が発生する可能性があるという警告がディストリビューションに表示されますか？ファイアウォールでポートが開いている場合は？）

私のように非常に消極的ですが、この古代のスレッドを再び復活させるために、この問題が発生している既存のマシンでこの問題を回避する方法について、意味のあるアドバイスはまだありません。

これはtldrでの私の最善の努力です。 スレッド全体。 このスレッドを見つける他の人に役立つことを願っています。

発生した問題

ボリュームには、 /var/lib/dockerあるかなりの（そして増加している）スペースがあり、ext3を使用しています。

解決

あなたは運が悪い。 ファイルシステムをアップグレードするか、下部にblowing docker awayを表示します。

発生した問題

ボリュームには/var/lib/dockerあるかなりの（そして増加している）スペースがあり、ext3を使用していません（たとえば、現在xfsまたはext4を使用しているシステム）

解決

標準のdockerコマンドを使用して、デバイスのスペースを再利用できる場合があります。

http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/を読む

次のコマンドを実行します。

docker volume ls
docker ps
docker images

これらのいずれにもリストされていない場合は、下部にあるblowing docker awayを参照してください。

古い古い画像や未使用のコンテナなどが表示された場合は、次の方法で手動でクリーンアップを実行できます。

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes
docker volume rm $(docker volume ls -qf dangling=true)

これにより、デバイスマッパーの非表示のコンテナースペースの多くが再利用されます。

Dockerを吹き飛ばす

動作しませんでしたか？ あなたは運が悪い。

この時点での最善の策は次のとおりです。

service docker stop
rm -rf /var/lib/docker
service docker start

これにより、すべてのDockerイメージが破棄されます。 これを行う前に、残しておきたいものを必ずエクスポートしてください。

最終的には、 https： //docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-for-productionをお読み

上記のアドバイスの使用に問題がある場合は、発生した問題に具体的に対処する新しいチケットを

rm -rf / var / lib / docker

nuke-graph-directory.shを使用することもでき

上記のようにファイルを削除した後、Dockerを起動できなくなりました。
Mar 02 04:53:40 pmdc001b dockerd [29522]：デーモンの起動エラー：graphdriverの初期化エラー：open / var / lib / docker / devicemapper / devicemapper / data：そのようなファイルまたはディレクトリはありません

CentOS 7.3でこの問題が発生し、3年以上存在するdevmapperの問題をデバッグしたくなかったので、このDC / OSガイドに従い、元のパッケージを削除し、overlayfsに切り替えましたが、すべて正常に動作しているようです。 ：https：//dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/（dockerバージョン17.03のExecStartコマンドを変更する必要がありましたが-> "dockerd --storage-driver =オーバーレイ "）

Server Version: 17.03.0-ce
Storage Driver: overlay
 Backing Filesystem: extfs
 Supports d_type: true
...
Operating System: CentOS Linux 7 (Core)

（ボリューム、イメージ、およびコンテナーのパージは役に立ちませんでした。/var/lib/docker内のものを削除すると、 ました）

docker system prune実行すると、マシンの多くのスペースが解放されました。

https://docs.docker.com/engine/reference/commandline/system_prune/

まあ、これは一種の...ラメです。

私の場合、Dockerをアンインストールして/var/lib/dockerディレクトリを削除した後にこの問題が見つかったため、 service docker stop ... service docker start相当するものを実行できません

私のシステムは、 /var/lib/dockerを解放されたものとして削除することで、スペースを報告していないことがわかりました（私は、最大14 GBが手に負えないように見えました）。

これに対する修正は、ファイルシステムを単にリロードすることです。私の場合、再起動したばかりで、スペースが再利用されました。

それがまだ問題だとは信じられません！ みんな来て、私はまだそれを持っています

@ shahaf600どのバージョンのhttps://github.com/moby/moby/issues/3182#issuecomment -228298975

詳細がなければ、あなたの状況について言うことはあまりありません。 あなたのケースは別の問題が原因である可能性がありますが、同様の結果になります。

良い

これらのゴミを購入し、サポートの状況を確認した後、返品しました。

最初の問題は@misterbigstuffです...オープンソースのものを購入しましたか？

そしてそれを返しました