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

疑問を呈したのは、 >>もし「メタデータも考慮しないのか！」とレベルの低さを嘆かれるようであれば、 >>LPIC/LinuCとかでは役不足かなと思いますので、期待するレベルに合う別の認定 >>資格をお探しになった方が良いかもしれません。 という、ping-tのこの1問がLPIC/LinuC全体のレベルを表す、という前提がないと成り立たない飛躍した意見が急に出て驚いたためです。根拠のない思い込みをしているではないか、というのを確認する為のものでした。 当然ながら、過去問をそのままは使用していないはずですし、監修もされていないはずなので、ping-tの全問題がLPIC/LinuCにおいて絶対に正しいという保障はありません。ping-tの問題が合っていようが間違っていようがLPIC/LinuCのレベルとは関係なく役不足かどうかとは関係ないということです。 ハードリンクの話に戻りますが、 >>「ハードリンクは複製のように見えるがそうではなく、どちらもディスク上の同 >>じデータを指す」「複製(copy, duplicate)は完全に別のエントリであり、 >>別のディスク領域を占有する」と説明されており、対比することで「ハードリン >>クはコピーと異なりディスク領域を別途占有しない」と理解させようという意図 >>が読める記述があります。 ここでの事実は ・複製は別のエントリで別のディスク領域を専有する (複製->専有) ・ハードリンクは複製でなくディスク上の同じデータを指す (ハードリンク->!複製、ハードリンク->エントリ) ということであり、 ・ハードリンクはディスク領域を別途専有しない(ハードリンク->!専有) の十分条件は満たせていないので、そのような意図を読むことはできないと思われます。(複製->専有であっても!複製->!専有にはならない) また、 >> > 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. においては、あくまで「通常ファイルのようにrmやmvが使える」であり、「ハードリンク->通常ファイル」とは読めませんでした。 私の関心である「ハードリンクはディスク容量を消費するか否か」は、 ・ハードリンクはエントリである(ハードリンク->エントリ) ・エントリはディレクトリの確保済みサイズを超過するとディレクトリサイズを増加させる(エントリ|確保済みサイズを超過->ディレクトリサイズ増) ・ディレクトリサイズが増えればディスク容量を消費する(ディレクトリサイズ増->ディスク容量消費) ということから、 ・ハードリンクはディスク容量を消費しないわけではない (ハードリンク|確保済みサイズを超過->ディスク容量消費) とほぼ解決済みで、いつでも議論を終了できると思っています。論点がLPIC101の試験範囲であるか否かに移っていますが、これに関しても、 ・ハードリンクやエントリ、ディレクトリのディスク容量消費に関する記述はない という結論でいいのではないでしょうか。(ファイルシステムに依存する部分があるので書いてない可能性もある)

>>このレベルで想定する運用観点で考えれば、この問題も私の認識でも「0バイト >>（ディスク容量消費なし）のファイルは存在する」というのは妥当な理解です >>が、これまでのharmoさんのお話を踏まえると「データとしては0バイトかもし >>れないが、dentry分ディスク容量を消費しているのだから0バイトではない」 >>となってしまい、小学校理科の知識を高校レベルで否定している感が否めませ >>ん。 ・ファイルは{inode,データ} ・データサイズもしくはディスク消費量は{inode,データ}のデータ部のサイズ。 ・ハードリンクはそもそもファイルではなくエントリ ・エントリはディレクトリファイルのデータ部に記述。 ・エントリが増えるとディレクトリデータ部の容量が増えるのでディスク容量消費 ・ハードリンク作成しても増加量が0byteに見えるのはディレクトリの容量確保が4096byte単位であるため、全エントリ容量がそれに満たない場合は変化しないだけ ということで何の矛盾もないとおもうのですが… https://learning.lpi.org/ja/learning-materials/101-500/ のPDFには 「元のファイルの2つ目の名前だと考えてください。コピー（複製）ではありません。ディスク上の同じ場所（inode）を指す別の項目（エントリ）です。」 「ハードリンクを作成することは、TARGETと同じinodeを指す、LINK_NAMEというディレクトリエントリを作成することです。」 と書いてあったので、公式としてはハードリンク=(ディレクトリ)エントリであり、これはLPIC101の範囲なのではないでしょうか。 また英語版である https://learning.lpi.org/en/learning-materials/101-500/ には 「Think of a hard link as a second name for the original file. They are not duplicates, but instead are an additional entry in the filesystem pointing to the same place (inode) on the disk」 「Hard links are entries in the filesystem which have different names but point to the same data on disk.」 と書いてあり、hardlink = (additional)entry ということで日本語版とほぼ同じ意味でした。 一方で「ディレクトリエントリがディスク容量を消費する」ことはLPIC101の範囲でないかもしれませんが、範囲か否かを焦点とするならば、上記PDFや黒本では「元ファイルを複製しない」旨の記述はあれど「ディスク容量を消費するか否か」は触れられていない為、この選択肢自体がLPIC101範囲外であり出題が不適となってしまうのではないでしょうか。(もちろん過去問として出題された実績があれば別ですが) そして疑問なのですが、ping-tやこの問題にはLPIC/LinuCとどのような関係性があるのでしょうか。この問題がLPIC/LinuCのレベルを表すものと捉えられているようですが、そう考えられた理屈がよく分かりません。ping-tの問題は全てLPIC/LinuCの方が監修されていたり、全て過去問として出題された実績があるということでしょうか。一般的にはこのようなサービスは資格団体と独立していて、それが資格試験全体のレベルを示す証明にはならないと思うのですが…

1.について ファイルとはあくまで{inode,データ}のことであり、ディレクトリが持つ管理情報が{名前,inode}だと私は解釈しています。今回の例だとデータの実体は{1457210,データ}であり、名前であるoriginal_fileとはあくまで{original_file,1457210}という管理情報(inode番号の別名)です。そのため名前：original_file->inode:1457210->データとアクセスすることができます。そして私が述べていた「メタデータ」も「マッピング情報」も共に{名前,inode}という管理情報です。 2.について lnで作ったハードリンクもtouchで作った名前もどちらも{名前,inode}という管理情報であり恐らく2つに明確な違いは存在しません。同じinodeに対する1つ目の{名前,inode}の管理情報を通常ファイル、2つ目以降の{名前,inode}の管理情報ハードリンクと言っているだけであると考えられます。したがってoriginal_fileを削除してもそれは{名前,inode}という管理情報の削除でしかなく、同様にhardlink_fileを削除することも管理情報を削除することでしかありません。どちらも削除してリンク数が0になると実体である{inode,データ}が削除されるのはメモリにおけるガベージコレクションのようなシステム側の作用であると思われます。 3.について メタデータという表現が広く解釈できてしまってややこしかったかもしれません…。ここでの「メタデータ」とは「ディレクトリが持つ管理情報」である{名前,inode}であり、inode番号の別名です。 ディレクトリもファイルであるためその実体は{inode,データ}であり、そのデータ部に{名前,inode}という管理情報を保持していると思われます(このディレクトリ自身の管理情報は上位のディレクトリが保持しているはず)。lnコマンドでハードリンク作成をすることは、ディレクトリ実体のデータ部に管理情報を追加することであり、ディスク容量を消費することになります。touchコマンドの場合は新たに{inode,データ(空)}が確保されるものの、管理情報の追加はlnと同様であると思われます。ただし先の実験から、容量が増加するタイミングはディレクトリが事前に確保した容量をオーバーした時だけのようです(+4096byte)。

次のページにUnix/Linuxのファイルシステムについて詳しく書いてありました。 (あくまで私の考察に近いというだけで正しいかは分かりませんが…) https://teaching.idallen.com/cst8207/13w/notes/450_file_system.html#file-systems-contain-names-of-directories-and-files File and directory data is actually stored under inode numbers, not under names. Directories map the names to the inode numbers for you. や Multiple names for the same inode are called “hard links”. という部分等から、 ・通常ファイルとは一意のinodeを持つファイル実体であり固有の名前を付けることはできない。 ・普段ファイル名として扱っているのは、ディレクトリが持つinodeへのマッピング情報である。 ・既存inodeへの別名のマッピング情報を特にハードリンクという。 と解釈できます。 touchとlnの違いも、新たなinode(ファイル実体)追加+inodeとファイル名のマッピング情報の追加と、既存inodeとファイル名のマッピング情報の追加、という程度の違いなのかもしれません。

私は「ハードリンク=ディレクトリファイルの実体が保持する名前とinodeポインタの組」、いうなればメタデータこそがハードリンクの本体であり、ハードリンクというファイルは存在しないのではないかと思いました。 ハードリンクを増やしていくとディレクトリのサイズのみが増加することから、ハードリンクはディレクトリ実体内にのみ保存されているデータであり、独立した実体を持っているわけではなさそうな為です。 （といってもディレクトリの実体を開くことはできないので確認できないのですが…)

返信ありがとうございます。 もしかしたら「機械的な」の言葉の解釈に齟齬があるのかもしれません… 解説の中でHDDは「衝撃によりプラッタに傷がついてデータが破損する場合があります」、SSDは「非接触メディアであるため耐振動・衝撃性が高く」という説明があったため、外的要因の振動や衝撃等の機械的(mechanical:力学的)な故障を含め「機械的な故障」と解釈していました。 そのため、基盤やコンデンサ等の回路上の部品破損も、あくまで振動や衝撃による「機械的な故障」として起こりうる例として出したつもりでした。

回答ありがとうございます。 確かにインターフェースで例えるのは不適切でしたので、基盤やコンデンサの破損等で例えた方が良かったですね。 ご指摘ありがとうございます。 「破壊」と「故障」については厳密に分けることができるのか、「故障」は内的要因にのみ使う言葉なのかといった疑問がありよく分かりません。ある時の外的な破壊行為が後の故障を早めるといったことはありますし、劣化やエージングの原因となる「振動」や「熱」が、使用によるものか故意に与えたものかを区別するのは難しそうなので…

回答ありがとうございます。 問題IDの異なる全く同じ問題が存在するのは盲点でした。 しかしリンク先でもこの問題は解決されていないようでした。 そこで以下の２点 ・0byteで無限の情報を保存できるわけがないため必ずディスク容量を消費するはずである ・ハードリンクを作成してみても1byteも消費していない から、固定サイズのメタデータ格納用ファイルが作られているのではないかと考え、次の実験をおこないました。 1.ファイル名255byteのハードリンクを作成 2.ハードリンクが存在するディレクトリのサイズを確認 3.以上繰り返し その結果、ディレクトリ初期サイズの4096byteを超えると新たに4096byteが確保され、以降現在のサイズを超えると4096byteずつ増加する、ということが分かりました。 したがって、問題ID15004及び3701は「ハードリンクはディスク容量を消費しない」は間違っていることが分かりました。

回答ありがとうございます。 私も改めて考えてみましたが、例えばデータ転送部の端子の破損など、HDD,SSD,USBメモリで似た性質の箇所の機械的な故障も存在する中で、あえて磁気ディスクのようなHDDに特有の故障のみを指す、とは文章から読めない為違うのではないかと思いました。 しかし「HDDのような機械的な故障が起きない」を「HDDのような可動部の故障が起きない」といったHDDに特有の故障に限定する記述に訂正するのはよいと思います。