別々のNASデータセット間でハードリンクを使用できますか？

いいえ。ハードリンクは同一ファイルシステム内の同じ inode を参照する必要があり、別々のデータセットやマウントでは通常 EXDEV が返されます。

この判断は、整理ツールや重複排除ワークフローで、別々の NAS データセットに保存されたライブラリ内に同じファイルを表示したい場合に重要です。競合する状態は、同一ファイルシステム上のハードリンクと、ファイルシステム間のコピー、reflink、クローン、またはアプリケーションによる参照です。保存済みの設定と使い捨てデータから始め、一度に1つの分岐だけを確認し、データ損失、権限、可用性のリスクが拡大する場合は中止してください。

データセット間のハードリンクに関する判断の条件を定義する

変更前に、ソフトウェアとファームウェアのバージョン、デバイス ID、マウントまたはネットワークパス、空き容量、権限、確認できる症状を記録します。ベースラインには、整理ツールや重複排除ワークフローで、別々の NAS データセットに保存されたライブラリ内に同じファイルを表示したい状況を再現するのに十分な詳細を残す必要があります。

最初の候補は、同一ファイルシステム上のハードリンクです。2つ目は、ファイルシステム間のコピー、reflink、クローン、またはアプリケーションによる参照です。現在の link システムコールの制限は、テストで使用する仕組みまたはコマンドの境界を定義しますが、この特定のホームサーバーでの観察に代わるものではありません。

判別テストを実行する前に、合格条件と中止条件を書き出します。合格とは、一方の分岐が予測した証拠が変化し、無関係なサービスは変更されないことです。失敗時は、推測に基づく修正を連鎖的に実行するのではなく、保存済みの状態に戻せる必要があります。

元の要件を下げずに主張を検証する

次の判別テストを使用します。デバイス ID を比較し、同一データセットのパスとデータセット間のパスの両方で、使い捨てのリンクを試みます。変更した変数に結果の原因を帰属できるよう、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

ハードリンクの境界を使って、分岐を実際に分けられる項目を選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショット ID、レイテンシ、転送バイト数、権限、復旧状態を記録します。主張の対象が ID、耐久性、またはアプリケーション状態である場合、コマンドが正常終了しただけでは不十分です。

再起動、再接続、再マウント、またはキャッシュのコールド状態が元の条件に含まれる場合は、そのイベントの後にテストを1回繰り返します。最初の実行で破壊的な変更が起きる場合や、環境を復元できない場合は中止し、使い捨てのコピーで再現してください。

stat -c "%d %i %h %n" source target
ln source cross-dataset-target

合格、失敗、例外の結果を解釈する

合格：同一データセットのリンクでは inode とリンク数が共有され、データセット間の試行はデータを変更せずに失敗する。結論が普遍的な主張にならないよう、合格した正確なバージョン、ID、ワークロードを記録します。

失敗：ツールがリンクの代わりに暗黙的にコピーするか、バインドマウントによって実際のファイルシステム境界が分かりにくくなっている。ネットワーク、メモリ、権限、ソースの一貫性が両方の分岐に影響する可能性があるため、失敗だけで自動的に反対の分岐が証明されるわけではありません。エスカレーションする前に、共有依存要因を切り分けてください。

例外または曖昧な結果：保持要件に基づいて、明示的なコピー、サポートされている reflink、またはデータセット境界の再設計を使用します。復元可能なコピーが存在するまで、ログを保持し、修復、削除、破棄、再パーティション、再帰的な所有者変更のコマンドは実行しないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

元のワークロードで判断を確認する

確認された分岐に対応する処置を適用し、その後、縮小した代替テストではなく元の条件を再実行します。同一データセットのリンクで inode とリンク数が共有され、データセット間の試行がデータを変更せずに失敗する状態が、2サイクル、または該当する再起動、スリープ、中断、負荷遷移をまたいで維持された場合にのみ、判断は有効です。

NFS ID マッピングを使って、最も近い依存ワークフローを確認しますが、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、復旧ポイントは、以前のアクセス状態とタイミングを維持する必要があります。

中止の境界は明確です。ツールがリンクの代わりに暗黙的にコピーする場合や、バインドマウントによって実際のファイルシステム境界が分かりにくくなる場合は、最後に検証された設定に戻し、証拠を保持します。その分岐が再現可能な場合に限り、より深いプラットフォームまたはハードウェアのテストへエスカレーションしてください。

目的の結果が得られたら、コンテナ UID マッピングと比較し、隣接するサービスへリスクを移していないことを確認します。新たなバックアップ、ID、タイムアウト、または可用性の障害が発生した場合、目的のテストに成功していても変更は失敗です。

FAQ

データセット間のハードリンクについて、通常残る疑問は、バインドマウントでデータセット間のハードリンクが可能になるか、データセット間でシンボリックリンクが許可されるか、reflink でハードリンクを置き換えられるかです。以下では、これらのエッジケースを主な判断から分けて説明します。

合格条件は変わりません。同一データセットのリンクで inode とリンク数が共有され、データセット間の試行はデータを変更せずに失敗することです。後続の条件でファイルシステム、ID、ネットワークパス、またはアプリケーションのバージョンが変わった場合は、その変更の影響を受ける判別テストだけを繰り返します。

ツールがリンクの代わりに暗黙的にコピーする場合や、バインドマウントによって実際のファイルシステム境界が分かりにくくなる場合は、実験を広げるのを中止してください。その時点で、明示的なコピー、サポートされている reflink、または保持要件に基づくデータセット境界の再設計を使用し、プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に証拠を保持します。

バインドマウントでデータセット間のハードリンクを可能にできますか？

いいえ。パスの見え方は変わりますが、基盤となるファイルシステム ID は変わりません。

データセット間でシンボリックリンクは許可されますか？

はい。ただし、シンボリックリンクにはパスが保存されるだけで、リンク先が消えた場合にデータは保持されません。

reflink でハードリンクを置き換えられますか？

対応しているファイルシステムでは、最初はブロックを共有しますが、変更すると独立したファイルになります。

データセット間のハードリンクについて、実際の答えは引き続き条件付きです。同一データセットのリンクで inode とリンク数が共有され、データセット間の試行はデータを変更せずに失敗します。ツールがリンクの代わりに暗黙的にコピーする場合や、バインドマウントによって実際のファイルシステム境界が分かりにくくなる場合は、明示的なコピー、サポートされている reflink、または保持要件に基づくデータセット境界の再設計を使用してください。元のワークロードに耐えられない部分的な成功は、互換性とは見なせません。