Zfs: 機能リクエスト-オンラインスプリットクローン

zfs promoteはすでに必要なことをしているようです。

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

私はzfsプロモートを見ていましたが、これは親子関係を反転させるだけのようです...

私が考えていたのは、両方のファイルシステムが互いに完全に独立している最終状態でした...

これのいくつかのユースケースは
VMテンプレートの複製-他のVMを作成するために複製されるベースイメージがあり、テンプレートから分割されるため、テンプレートを更新/破棄/再作成できます。
データベースクローン-多くの変更が加えられ、テストクローン自体のベースとなる可能性のある開発用のprod dbのクローンを作成します。これは、ベーススナップショットが大きくなる可能性があるため、devをprodから分割すると便利な場合です。開発用の独立したファイルシステムを持つよりも

original @ snapshotのクローンを作成した後、データセットとクローンの両方を自由に変更できます。ディスク上の両方に共通のデータを共有することを除いて、相互に影響はありません。

テンプレート（オリジナル）を破棄/再作成する場合は、テンプレート上のすべてのスナップショット（クローンのオリジンとして使用されるスナップショットを除く）を破棄するだけで、zfsはoriginalの名前を変更し、zfsは同じ名前（originプロパティ）で新しいスナップショットを作成しますクローンの数は元のデータセットの名前にバインドされていないため、両方の名前を自由に変更できます）。

唯一の欠点は、 original @ snapshot （=クローンのベース）に保持されているすべての_unique_データを、クローンまたは（クローンのプロモート後）オリジナルを破棄する意思がない限り解放できないことです。

@ greg-hydrogenは、最終的にzfs promoteがニーズを満たしているかどうかを判断しましたか？ または、ここで機能リクエストの可能性がまだありますか？

これについてコメントするには、オリジンとクローンの関係を重複排除された種類に変換する機能があると便利です。データセットが個別に破壊されないようにする論理リンクを削除し、共有されたままのコピーを1つだけ維持します。データ。

@behlendorf ：それはほぼ確実にニーズを満たしていません。
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
問題をうまく説明します。

これが私が概念的にやろうとしていることです：

user @ backup ：

1. 日付ベースのスナップショットを生成する
2. バックアップから送信してミラーとしてテストする

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

user @ test ：

1. 鏡を消毒する場所を作る
2. それを消毒する
3. スナップショット
4. 使用するためにサニタイズされたバージョンのクローンを作成する
5. これを使って

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

user @ backup ：

1. さらに生産を使用した...
2. 更新されたスナップショットを作成する
3. 製品からテストへの増分変更を送信します
4. 以前のインクリメンタルマーカーを削除します（私の場合は70GBを解放します）

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

user @ test ：

• ここに問題が発生します。
• ある程度のキャジョリングで、消毒ボリュームを破壊することができます。
• しかし、残りの2つのもの（ test/mirror@20170908とtest/test ）の原点であるtest/mirror@20170901が残っています。
• 必要に応じて、更新されたミラー（ test/mirror@20170908 ）を破棄することもできますが、それでは何の役にも立ちません（私の目標はそのデータを使用することであるため）。

私が進歩するためには、実際にサニタイズを実行し、テストを使用しているものを停止し、テストを（完全に）破棄し、ミラーをテストとして複製し、テストを使用して再開する必要があります。その後、最終的に元のオブジェクトを破棄することができますスナップショット。 または、パスを取得し、後でバックアップ時に新しいスナップショットをトリガーし、その増分を送信して、テスト用にミラーリングされなかったスナップショットを削除して、再試行することを決定できます。

Fwiw、これを味わうために...：

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

（数値は本当に間違っています。実際には、1つのボリュームと4つのボリュームが含まれているため、再帰フラグが...）

これで、 zfs send | zfs recvを使用して依存関係を解消できること、そして小さなことでも問題ないことを理解しました。 しかし、私のプールのこの部分は、プール内の使用可能なスペースの約2倍であり、半分はおそらくそれよりも大きいため、その操作の実行には問題があります。 また、再処理するのは膨大な量のバイトです。 スナップショットを使用することでの私の希望はCOWの恩恵を受けることでしたが、代わりに、分岐ツリーのどちらの側でも使用されるデータを最終的に持つ分岐点に対して料金を支払う必要があるため、COWの料金が請求されます。

@behlendorfこんにちは、これについて何か進展はありますか？ 元のファイルシステムからクローンを分割することは、VMテンプレートや大きなファイルレベルの復元に非常に役立ちます。 実用的な例については、上記に貼り付けたリンク@jsorefを参照してください。

@kpande ：目標は、データセット全体（この操作が発生するたび）ではなく、変更されたもの（COW）に対して（スペースおよびデータ転送で）支払うことです。

10TBの移動データセットと、確立したいデータセットのバリエーションがある場合は、確かに、10TBをコピーしてバリエーションを適用し、20TBを支払うことができます（20TBが利用可能な場合）。 しかし、私のバリエーションが実際には元の10TBとわずか10MB異なる場合、なぜ10TB + 10MBを支払うことができないのですか？ -スナップショット+クローンは私にそれを与えます。 10TBが十分に移動して10TB（ライブ+ 10TBスナップショット+ 10TB分岐）を支払うまで、10MBバリエーションが移動して独自の10TB（ライブとスナップショットの両方から分岐）になります。 暫定的に、30TBの問題を「修正」するには、さらに10TB（= 40TB-zfs send + zfs recv経由）を費やす必要があります。 それは理想的ではありません。 確かに、それは「機能」しますが、「高速」でも、リモートでスペース効率も良くありません。

編集されたsend / recvは面白そうに聞こえます（私のユースケースとほぼ一致しているため）-しかし、それが多くの場所で言及されているのを見つけることができますが、実際に編集されているものの有用な説明を見つけることができません。

Fwiw、私たちのシステムでは、サニタイズが送信側で行われるように切り替えました（これはプライバシーの観点からも優れています）。これにより、ほとんどの場合、森から抜け出しました。

データバリエーションが「編集」されておらず、システムにzfsスナップショット+ zfs送信用のリソースがあるが、「変更」を行うために2番目のデータベースをホストするためにリソースを割り当てたくない場合があります。プライマリとセカンダリの間でボリューム全体を送信するために料金を支払う必要はありません（つまり、以前のスナップショットがすでにあるシステムに増分スナップショットを送信する方がよいでしょう）。

はい、重複排除を使用できることは承知しています。 私たちはCPU / RAMにお金を払っているので、まれなタスク（変異したクローンの更新）をすばやく作成するために一定のCPU + RAMを割り当てることは、トレードオフとしては不十分だと感じました（ディスク容量を少し増やしたいと思います）。

@kpandeこのリンクは、現在のクローンの問題を非常に明確に示しています。 結局のところ、クローンがベーススナップショットから大きく逸脱している場合、2つの間の永続的な親子関係が混乱の原因になります。 クローンを分割することは、それらがあまりにも分岐していて、もはや結び付けられているとは見なされないことを明確に示しています。

しかし、もっと実用的な例を挙げましょう。

kvm/vmimagesを複数の仮想ディスクイメージのデータストアコンテナとし、スナップショットを毎日取得します。 デフォルトの答えは「ディスクごとにデータセットを使用する」であることは知っていますが、libvirtプールはそれでうまく機能しません。 したがって、次のようなものがあります。

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

ある時点で、vmディスクに何か悪いことが起こります（つまり、深刻なゲストファイルシステムの破損）が、その間に他のユーザーが他のディスクに新しい重要なデータを積極的に保存しています。 基本的に、いくつかの対照的な要件があります。a）昨日の破損していない古いデータに戻す、b）スナップショットにないアップロードされた新しいデータを保持する、c）サービスの中断を最小限に抑える。

考えられる解決策としてクローンが思い浮かびます。 kvm/vmimages@snap3をkvm/restoredとしてクローンして、影響を受けるVMのサービスをすぐに復元できます。 だからあなたは今持っています：

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

影響を受けるVMはkvm/restoredから実行されますが、他のすべてのVMはkvm/vmimagesです。 この時点で、 kvm/restoredからすべての余分なディスクを削除し、 kvm/vmimagesから元の破損したディスクを削除します。 古い破損したディスクイメージがまだ実際のディスクスペースを使用していて、 kvm/restoredを上書きすると、古い削除できないkvm/vmimages@snap3ために追加のスペースが消費されることに気付くまで、すべてが順調に見えます。 また、あなたのクローンを削除せずに、この古いスナップショットを削除することはできません、あなたは単に宣伝することはできませんkvm/restored 、削除kvm/vmimages実際のデータは、次のとおりです。それが唯一の真の「権威」データソース（つまりはないので、両方のデータセット内に保存されます）。

ソースからクローンを分割すると、上記の問題は完全に解決されます。 この場合、編集されたsend / recvがどのように役立つかは私にはわかりません。

@kpandeまず、あなたの見解と解決策を共有してくれてありがとう（これは興味深いです！）。 注意深く、非常に具体的なゲスト構成（およびホストデータセットツリー）によって、上記の問題を回避できることに完全に同意します。

とは言うものの、libvirt（およびそのストレージプールの実装）は、特にWindows仮想マシンとの混合環境を管理する場合、このアプローチではうまく機能しません。 さらに、これは1つの例にすぎません。 分割可能なクローンは、たとえば、「ゴールドマスター/ベースイメージ」を作成するために使用する場合に非常に役立ちます。これは、「実際の」仮想マシンを作成するために自由にインスタンス化できます。

現在の状況では、元の、潜在的に廃止されたスナップショットを削除することはできないため、

引用符で囲まれた世界を「単純に」使用したことに注意してください。これは確かに単純な論理演算ですが、基になるzfsファイルシステムにどの程度適切にマップされるかはわかりません。

@kpandeわかりました、十分に公平です-実際の技術的な問題が存在する場合、私はそれを受け入れる必要があります。 ただし、これは、特定のユースケースが無効であると述べることとは異なります。

このビュー（つまり、「神話上の」BPRを使用せずに元の親スナップショットからクローンを分割できない）がzfs開発者によって共有されている場合、このFRを閉じることができると思います。

ありがとう。

この機能が必要な場合は+1。 はい、send / recvを使用できますが、古い（クローン）データセットから新しいデータセットに切り替えるために、そのデータセットを使用しているものすべてのダウンタイムが必要になります。

LXDでコンテナーがコピー（複製）される状況に遭遇しましたが、それにより、個別に管理されているスナップショットで問題が発生します。

@kpande ：繰り返しになりますが、私のユースケースでは、データセット全体がデータベースであり、データベースのバリエーションがいくつかあります。

私が見たところ、overlayfsがファイルシステムとしてzfsを使用してうまく再生されているようには見えません（メモによると、zvolsとext4 / xfsを使用して満足しているようです）。 このアプローチはほとんどの場合をカバーするように_聞こえます_。その場合、ext4 / xfsを使用してoverlayfsを設定する方法を説明するドキュメントを歓迎します。

そうは言っても、私たちの中には、ボリューム管理だけでなく、acl / allow / snapshotの動作/ブラウジングにもzfsを使用していて、ext4 / xfsの代わりにzfsを使用したoverlayfsを使用できるようにしたいと考えている人もいます。不可能ですが、そのためのバグはありますか？ ある場合は、それが（ここから）強調表示されているとよいでしょう。そうでない場合は、overlayfsアプローチを承認している場合は、ファイルすることができます（主張する場合は、おそらく書くことができますが、私はしません）オーバーレイについては何も知りませんが、それは記事の重要なテクノロジーのようです）。

私が見たところ、overlayfsがファイルシステムとしてzfsを使用してうまく再生されているようには見えません（メモによると、zvolsとext4 / xfsを使用して満足しているようです）。 このアプローチはほとんどの場合をカバーするように_聞こえます_。その場合、ext4 / xfsを使用してoverlayfsを設定する方法を説明するドキュメントを歓迎します。

overlayfsアプローチは、非常に重要で一般的なユースケースでは機能し

@ ptx0これは、ゲストOSがoverlayfsサポートしている場合（つまり、Windows VMはサポートされていない場合） 、およびエンドユーザー（つまり、お客様）がVMイメージのプロビジョニング/インストールを大幅に変更する意思がある場合にのみ機能します。 ちなみに、私はこのPRが技術的にクローズされていることを完全に理解しており、受け入れていますが（たとえば、BPRが含まれている場合）、正当なユーザーケースに「無効」のスタンプを付けるのは非常に苛立たしいことです。 ユースケースでない場合は、問題ありません。 ただし、この機能の有効な使用例を誰も持っていないと思い込まないでください。

Windowsはoverlayfsを必要とせず、フォルダリダイレクトと移動プロファイルが組み込まれています。

フォルダリダイレクトはNT以降存在しますが、（あいまいな理由で）リダイレクトされたフォルダを正しく処理せず、リダイレクトされたデスクトップまたはドキュメントに直面すると単に失敗するソフトウェアが存在するため、常に信頼できるとは限りません。 それとは別に、Windows Updateのおかげで、Windowsインストールのクローンは、それ自体で、元の場所から大規模かつ非常に迅速に分岐します。異なるユーザーがログオンおよびログオフすることで、これが高速化されるだけです。