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