arashi1977さんの助け合いフォーラム投稿一覧

ありがとうございます。クリアにしたい部分がクリアにならなかったのでお尋ねするのですが > という部分等から、 > ・通常ファイルとは一意のinodeを持つファイル実体であり固有の名前を付けることはできない。 > ・普段ファイル名として扱っているのは、ディレクトリが持つinodeへのマッピング情報である。 > ・既存inodeへの別名のマッピング情報を特にハードリンクという。 > と解釈できます。 1. 前のコメントの抜粋なのですが、 > $ touch original_file > $ stat original_file > File: original_file > <SNIP> > Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode: 1457210, リンク数は1 ここでは元ファイルのinode番号が1457210となっており、このoriginal_fileが「一意（1457210）のinode番号を持つファイル実体」のことだと理解しました。（「固有の名前をつけることはできない」については意図が理解しきれませんでした。original_fileという名前をつけられない、という意味？） 上記のstatコマンド出力の2行目でファイル名（original_file）が見えていますが、この「ファイル名」そのものがinodeへのマッピング情報を意味するということでしょうか？それともマッピング情報が「original_file」というファイル名を意味しているということなのでしょうか？ また、「マッピング情報」と「メタデータ」は同一のものと理解して良いのでしょうか？ 2. 上記のファイルについて、ls -liコマンドで確認すると、どちらも同じinode番号を示しています。（これはハードリンクなので当然だと理解しています） > $ ls -li | grep _file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 hardlink_file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 original_file また、この出力の3列目の「2」は「ハードリンク数」を示していると確認しています。この状態でoriginal_fileを削除すると以下のようになります。 > $ ls -li | grep _file > 1457210 -rw-rw-r-- 1 user user 0 Jun 23 19:17 hardlink_file ハードリンクではなく元ファイルを削除したのに「ハードリンク数」が減少しています。また、この残っているファイルを元にしたハードリンクを作成することもでき、そのinode番号も同じものです。 > $ ln hardlink_file another_file > $ ls -li | grep _file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 another_file > 1457210 -rw-rw-r-- 2 user user 0 Jun 23 19:17 hardlink_file この時以下の点についてどう理解すれば良いのかが整理できません。 > 「ハードリンク=ディレクトリファイルの実体が保持する名前とinodeポインタの組」、いうなればメタデータこそがハードリンクの本体 > ・既存inodeへの別名のマッピング情報を特にハードリンクという。 「メタデータがハードリンクの本体」であれば、ハードリンクに対するハードリンクを作成した場合「メタデータ（＝名前とinodeポインタの組）への別名のマッピングとなるメタデータ（メタデータへのinodeポインタとなるメタデータ）」を作成した、ということなのでしょうか？ また、original_fileを削除したということは、メタデータであるhardlink_fileのみが残り「一意のinodeを持つファイル実体」である通常ファイルは消えたという理解で良いのでしょうか？ ハードリンクが通常ファイル（という表現で良いのか？）の同じinodeへの参照であれば同じデータを複製することなく異なるファイルとして存在できるので「ディスク容量を消費しない」というのが成立するという理解であったので、「ハードリンク＝メタデータ」と考えるには「ハードリンク元のファイルを削除する」というのが元ファイルの実データとの観点でどういうことなのかをクリアにする必要があると思っています。 3. 私の元々の理解では「inode≒メタデータ」だったので、同一inodeで管理する情報が増えたとしてもそれはメタデータ（というかファイルの実データ）が増えるのではなく「当該ファイルを格納するディレクトリが管理するデータ量」が増えることで増加しているものであり、ハードリンクそのものがディスク容量を消費してはいないという認識でした。ですが、ハードリンクは「メタデータ」とのことなので上記の認識を変える必要があるかなと思っています。 このやり取りの中で出てきている「メタデータ」とは「ディレクトリが持つ管理情報（マッピング情報？）」のことなのか、ファイルの実データに関する管理情報であるinodeなのか、それとも別の情報のことなのでしょうか？ （最初のコメントの「固定サイズのメタデータ格納用ファイル」の理解に必要な情報である認識です）

認識改のために考えていたのですが、わからなくなってきたので教えてください。 > 「ハードリンク=ディレクトリファイルの実体が保持する名前とinodeポインタの組」、いうなればメタデータこそがハードリンクの本体であり、ハードリンクというファイルは存在しない とのことですが、「ハードリンク」はファイルではないのでメタデータが本体だということであれば、「通常ファイル（という言い方が適切かも考え中ですが）」とは何なのでしょうか？ 上記のstatの結果からすると、ハードリンクもとのファイルとハードリンクのどちらも同じinodeが割り当てられている（＝同じinodeポインタを持つ）ということだと思ったのですが、通常ファイルとハードリンクはどこがどのように異なるものなのでしょうか？ ハードリンクと通常ファイルの違いについて明確に解説されたドキュメントもうまく見つけられず困っています。

そうなのですか！ ハードリンクがすでにあるファイル（実データ）への別名による参照だと理解していたので、どちらもファイルだと思っていました。 ーーー $ touch original_file $ stat original_file File: original_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode: 1457210, リンク数は1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:16.846932371 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 $ ln original_file hardlink_file user@containerlab:~/work$ stat hardlink_file File: hardlink_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 2 ←inode番号は同じで、リンク数が2に増えた Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:26.863098754 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 $ rm original_file　　←ハードリンク元のファイルを削除 $ stat hardlink_file File: hardlink_file Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 1457210 Links: 1 ←inode番号は変わらず、リンク数が1に減った Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2024-06-23 19:17:16.846932371 +0900 Modify: 2024-06-23 19:17:16.846932371 +0900 Change: 2024-06-23 19:17:31.915182665 +0900 Birth: 2024-06-23 19:17:16.846932371 +0900 ーーー 「Unixではすべてのリソースがファイル」という概念を昔学んだのが根本にあったので「ハードリンクもファイル」という認識でいましたが、今は変わっているのですかね。認識を改めねば。

もしご存じだったら教えてください。 当然だと思ってて気にしてなかったのですが、「ハードリンク」と「ハードリンクを作成することで記録されるメタデータ」って同一視すべきものだったりするでしょうか？ ハードリンクは「ファイルシステム上の同じデータを指す」ファイルだと理解していたので追加で容量消費しないのは当然だと思っており、逆にメタデータは「ファイルシステムの管理情報」なので管理対象となるハードリンクが増えることで「メタデータ」が増えるのは当然だとも思っています。 で、そうすると「ハードリンク＝ハードリンクのメタデータ」とはならないんじゃないかな？と思ってたのですが「”ハードリンク”と”ハードリンクのメタデータ”は異なるものだという私の理解がそもそも間違ってる…？」と心配になってきました。

> もしかしたら「機械的な」の言葉の解釈に齟齬があるのかもしれません… はい、私もそこがポイントなのかもなぁとはうっすら感じていました。 ご質問の時点で > SSDやUSBフラッシュメモリは可動部品がないので機械的に壊れにくいだけ とおっしゃっていたので、「可動部品の有無について言及されている＝機械をmachine（部品を組み合わせた装置）とした前提で会話可能」と判断していたのですが、 > 外的要因の振動や衝撃等の機械的(mechanical:力学的)な故障 と「力学的」という前提で会話されていたのだということがわかってスッキリしました。 前提が違ったら会話もすれ違いますよね(^^; なお「ドライブ（記憶装置）」の観点で、使用中のSSDに対して「力学的故障」が発生するシーンというのはパッと思い浮かばなかった（それこそ天災や不慮の事故ぐらい？）ので、やはり最初に言及したように > 曖昧さ回避のために「SSDとUSBフラッシュドライブは」を「SSDは」として「頻回な抜き差しや意図していない操作による破壊」を考慮外にできるように というのが、出題意図からすると妥当なのかなぁと改めて感じています。 （基盤にソルダリングされたSSDが力学的に壊れる＝SSD単体の観点じゃなくマザーボードごと壊れるという話でもありますしね） とはいえ、「機械的」を「機械（部品を組み合わせた装置）」「的（そのような性質）」と理解してこの問題を解く事に特に問題があるとは思いませんし、「機械的（mechanical）」を「力学的」と理解することを間違いだとも思っていません。 https://dictionary.cambridge.org/ja/dictionary/english/mechanical ですので、前者の意図で作成したであろうこの問題を間違っているということもharmoさんの考え方が間違っているということもできませんので、別のご質問と同じ結論になってしまいますが、「実試験で同様の選択肢があった場合でも、自信を持って当該選択肢を誤りと判断して別の選択肢を回答として選択される」というのが落とし所（っていうのも変ですが）かなと思います。

> 今は個体が多いからか 「個体」じゃなくて「固体」ですね (^^;

回答に記載した別の質問の中で > 試験では「ハードリンクとはどういうものか」が問われていると考えられますので、「動的inodeのファイルシステムでリンク先が重複する大量のハードリンクを作成した場合」という特殊な例を前提にはしていないと判断するべきかなぁと思います。 と記載しましたが、実験された内容に > 3.以上繰り返し と記載がありますので、この操作が通常運用で当然のものだというご判断なのだと理解しました。ですので > したがって、問題ID15004及び3701は「ハードリンクはディスク容量を消費しない」は間違っていることが分かりました。 ご提示の問題が間違っているかどうかについてコメントすることはありませんので、このやりとりによって、実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断した上で合格を勝ち取れればそれで良いと思います。

> 基盤やコンデンサの破損等で例えた方が良かったですね。 はい、その例示は適切かと思います。電源ユニットでも使ってたら煙吹いて使えなくなるとかよくありましたしね。（今は個体が多いからか、あまり聞きませんが） この場合は「回路上の部品破損」なので「機械的故障」ではないというのがはっきり見えて良いと思います。 後半についてですが、そもそもこの質問の主旨は > 「SSDとUSBフラッシュドライブは、HDDのような機械的な故障が起きない」という正答の選択肢 についてでしたので「機械的な故障」についての話だったと理解しています。 破壊行為や振動や熱といった外的要因を主眼に話を進めるのなら、それは「意図しない操作」や「（劣悪な）使用環境」という観点が優先になるように思ったので、掘り下げると違う方向に進んでしまってよくないかなぁと思いました。

あ、でもそう言う意図だと「バンドルするポートで共通」は変ですね。auto - autoやpassive - passiveだと接続確立しないですし。この辺の表現は適切に修正していただく必要はありそうですね。

お二人の発言を何度か読んで気づいたのですが、もしかして > 上記に加え、EtherChannelモード（LACP、PAgP、on）もバンドルするポートで共通にする必要があります。 ここを > 上記に加え、EtherChannelモード（active / passive / desireble / auto / on）もバンドルするポートで共通にする必要があります。 とするべきだ、と言うお話だったのですか？ そうだとしても、参考の【コマンド構文：EtherChannelの設定】の中でも channel-group 番号 mode { on | auto | desireble | passive | active } と記載があるように、モードとして指定できるのがこの5つですので「プロトコルを使うのか、使うのであればどのプロトコルでネゴシエーションを自分から行うのかどうか」と言う挙動についての設定をこの5つのモードから選ぶ、と言うだけなので、やはりプロトコルがどうとか難しいことを考えずに「モード」で何も問題はないのではないかなぁと感じました。

うーん、そうは言われましてもカーネルが /sbin/init を起動するのは事実ですしねぇ https://github.com/torvalds/linux/blob/master/init/main.c#L1523 もしかして「起動される」と「起動する」の言葉が問題だって言われてますか？ - プロセスとして起動されるのは　/sbin/init （プロセスとは実行中プログラムの管理に使われる単位なので、 /sbin/init と言うバイナリファイルを起動することで init プロセスが実行中となる） - initプロセスとして /sbin/init を起動するのは「カーネル」の役割。カーネルもプログラムだが、そのプログラムの実行処理の中で /sbin/init を起動するというものが実装されている と言うだけの話なのですが、どのあたりが腑に落ちない部分でしょうか？

yklvさんの返信＆ping-tさんの解説に補足すると、「^15$」って「行頭に1が来て、続いて5が来て、その次に行末がある」なのですよね。 「1に続けて5」と言う時点で、間に何も入ることはできないので > ^15$も12345という検索パターンに該当してしまいます。 と言うのは起こり得ないんですね。

yhayashi52さん コスト変更はできますがそれにより別の問題が発生します。具体的には問題ID: 23629 をご確認ください。