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

> ほぼ解決済みで、いつでも議論を終了できると思っています。 そうですね。これ以上続ける必要はないという点については私も同意見です。 別のご質問と同様に、最初の方で > ご提示の問題が間違っているかどうかについてコメントすることはありませんので、このやりとりによって、実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断した上で合格を勝ち取れればそれで良いと思います。 とコメントしたところで終わっていてもよかったのですが、「間違っている」と断定されていたので、私の理解を修正する必要があるかと思って追加のご質問をしてしまいました。 特にその必要もなさそうだということがわかりましたので。 > また、私のこれまでの理解（ハードリンク自体はディスク容量消費しない、dentryはディスク容量消費する）は何ら変える必要がないこともわかりました。 このコメントした時点で明確に「終わりにしましょう。」とお声がけするべきでしたね。 すみません。 長々とお付き合いありがとうございました。

この問題というか、harmoさんにとってのPing-tさんのコンテンツの利用目的がわからなくなってきたので、できればこれを最後にしたいところです… この問題（というかPing-tさんの学習コンテンツ）の利用目的に関わるので、まずは「疑問」から。 > そして疑問なのですが、ping-tやこの問題にはLPIC/LinuCとどのような関係性があるのでしょうか。この問題がLPIC/LinuCのレベルを表すものと捉えられているようですが、そう考えられた理屈がよく分かりません。 「どのような関係性」と言われても「当該試験合格に向けた学習問題」でしかないと思っています。ですので試験合格に必要な知識を学ぶためのものであり「この教材で学習して合格できる＝LPIC/LinuCで求められる知識レベルを満足している」と言えるという認識です。 > ping-tの問題は全てLPIC/LinuCの方が監修されていたり、全て過去問として出題された実績があるということでしょうか。 それは逆に問題かなと思います。 本屋や他のWeb学習コンテンツなどで「LPIC-1対応」とか謳っているものもある中で、Ping-tさんだけがLPIC(LPI)/LinuC(LPI-Japan)の監修を受けていたら不公平な待遇ですし、過去問をそのまま出していたら受験ポリシーに引っ掛かりますからそんなコンテンツは不適切と判断されて監修どころかNG食らう可能性の方が高いと思います。 ＃＃＃ここまでが「疑問」についてで、ここからは「ハードリンクはディスク容量を消費するか」についてのお話です。＃＃＃ 引用された部分からは「ハードリンクを作成することで追加エントリが作成される」は読み取れるものの「ハードリンクすることでディスク容量を消費する」とは読めませんでした。ここはharmoさんもおっしゃっている通り > ・ハードリンク作成しても増加量が0byteに見えるのはディレクトリの容量確保が4096byte単位であるため、全エントリ容量がそれに満たない場合は変化しないだけ と、「ハードリンクを作成しても増加量が増えない」場合を踏まえてのことだと理解しています。 逆に「They are not duplicates」と「複製ではない（ハードリンク元と同じディスク容量を要求しない）」とは読める記述があります。 加えて、英語版P.514の「3. Explain the difference between a hard link to a file and a copy of this file.」で > A hard link is just another name for a file. Even though it looks like a duplicate of the original > file, for all purposes both the link and the original are the same, as they point to the same data > on disk. や > A copy is a completely independent entity, occupying a different place on disk. 「ハードリンクは複製のように見えるがそうではなく、どちらもディスク上の同じデータを指す」「複製(copy, duplicate)は完全に別のエントリであり、別のディスク領域を占有する」と説明されており、対比することで「ハードリンクはコピーと異なりディスク領域を別途占有しない」と理解させようという意図が読める記述があります。 また、「Moving and Removing Hard Links」のセクションでも以下の通り「ハードリンクは通常ファイルとして扱われる」との記述もあるので、「ハードリンクはエントリでありファイルではない」は（厳密な実態がそうであるとしても）LPIC-1の想定する利用者運用者の観点では混乱の元かもなぁと思っています。 > Moving and Removing Hard Links > Since hard links are treated as regular files, they can be deleted with rm and renamed or moved > around the filesystem with mv.

> 「0バイト（ディスク容量消費なし）のファイルは存在する」というのは妥当な理解 ここちょっと補足すると、「中身のない0バイトのファイルを作成した」というのも「既存ファイル（実データあり）に対するハードリンクを作成したが、実データを複製したわけではないのでハードリンク自体は容量を持たない」というのも同じことだと判断できる、という意図です。

ありがとうございます。 （いただいた回答から、LPIC101が求めているレベルはいつの間にかdentryの利用に関する知識レベルになっていたのか？！と驚きを持って受け止めています ^^; ） > そして私が述べていた「メタデータ」も「マッピング情報」も共に{名前,inode}という管理情報です。 こちらのご説明から、これまでのやり取りは「メタデータおよびマッピング情報＝dentry」を意図していると確認できました。それでようやく当初ご質問の > ハードリンクのメタデータ(ハードリンク名や参照先iノード番号)の分 が理解できました。その前提に立てば、これまでのharmoさんのおっしゃっている内容に同意です。 また、私のこれまでの理解（ハードリンク自体はディスク容量消費しない、dentryはディスク容量消費する）は何ら変える必要がないこともわかりました。 LPIC Level1の求めるスキルは以下の通りです。 > LPIC-1は、候補者がコマンドラインでメンテナンスタスクを実行し、Linuxを実行するコンピューターをインストールして構成し、基本的なネットワークを構成する能力を検証します。 https://learning.lpi.org/ja/learning-materials/101-500/ このレベルで想定する運用観点で考えれば、この問題も私の認識でも「0バイト（ディスク容量消費なし）のファイルは存在する」というのは妥当な理解ですが、これまでのharmoさんのお話を踏まえると「データとしては0バイトかもしれないが、dentry分ディスク容量を消費しているのだから0バイトではない」となってしまい、小学校理科の知識を高校レベルで否定している感が否めません。 この問題はLPIC-1向けの学習問題ですし、求められている知識レベルに合わせた回答を意識しないと、以前のコメントの通り > 実試験で類似の問題が出題された際に「ハードリンクはディスク容量を消費しない」という内容の選択肢があった場合でも、harmoさんが自信を持って「これは不正解だ」と判断 するしかなくなり、自縄自縛になりかねないんじゃないかなぁと心配しています。 もし「メタデータも考慮しないのか！」とレベルの低さを嘆かれるようであれば、LPIC/LinuCとかでは役不足かなと思いますので、期待するレベルに合う別の認定資格をお探しになった方が良いかもしれません。

ありがとうございます。クリアにしたい部分がクリアにならなかったのでお尋ねするのですが > という部分等から、 > ・通常ファイルとは一意の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という検索パターンに該当してしまいます。 と言うのは起こり得ないんですね。