助け合いフォーラム

LPIC

LPIC Lv1-101(Ver5.0)
問題ID : 3701
問題を開く
ハードリンクとシンボリックリンクそれぞれの説明として正しいものはどれか。(3つ選択)

正解

ハードリンクはディスク容量を消費しない

ハードリンク先のファイルを編集すると、元ファイルも変更される

シンボリックリンクの元ファイルを削除しても、リンクは残る

解説

Linuxではファイル(ディレクトリはファイルの一種)を「ファイルの実体(データ本体)」と「inode」を使用して管理しています。inodeにはファイルの属性や、「ファイルの実体」にアクセスするためのアドレスなどのメタデータ(格納されているデータそのものに関する情報)が格納されています。

ハードリンクとは、ファイルの実体を直接参照するリンクのことです。同じ実体を参照するハードリンクは同じinode番号を持ち、複数作成してもコピーのようにディスク容量を消費しません。そのため、更新が無いファイルのバックアップ手段としてハードリンクが使用されることもあります。
また、ハードリンク先のファイルの中身を編集すると、元ファイルの中身も同じく変更されます。

シンボリックリンクとは、Windowsでのショートカットのようなもので、元ファイルの場所を指し示すリンクのことです。シンボリックリンクが持っている情報は「元ファイル(ディレクトリ)がどこにあるのか」というパス情報のみです。
シンボリックリンクの元ファイルを削除すると(他に同じinode番号を持つハードリンクが無ければ)、ファイルの実体は削除されますが、リンクは残ります。ただその場合、シンボリックリンクにアクセスすると、リンクしている元ファイルが無いためエラーになります。

したがって正解は
・ハードリンクはディスク容量を消費しない
・ハードリンク先のファイルを編集すると、元ファイルも変更される
・シンボリックリンクの元ファイルを削除しても、リンクは残る
です。

その他の選択肢については以下のとおりです。

・ハードリンクは異なるファイルシステムに作成できる
inode番号はファイルシステム毎に管理されるため、異なるファイルシステムへハードリンクを作成する事はできません。

・シンボリックリンクの元ファイルとリンクファイルのinode番号は同じである
シンボリックリンクはファイルの実体を指しませんので、inode番号は元ファイルと異なります。

参考

Linuxではファイル(ディレクトリはファイルの一種)を「ファイルの実体(データ本体)」と「inode」を使用して管理しています。inodeにはファイルの属性や、「ファイルの実体」にアクセスするためのアドレスなどのメタデータ(格納されているデータそのものに関する情報)が格納されています。
Linuxには、同じ「ファイルの実体」に対して複数の名前でアクセスできる、リンクという仕組みが2種類あります。それが「ハードリンク」と「シンボリックリンク」です。

【ハードリンク】
ハードリンクとは、ファイルの実体を直接参照するリンクのことです。ファイルを新規作成した場合は、ハードリンクが1つある状態です。
同じ実体を参照するハードリンクは複数作成できます。それらは同じinode番号を持つことになります。



上図のFile1とFile2は同じ実体を参照しています。ですのでFile1の中身を編集すると、File2の中身も同じく変更されます。

ハードリンクの数とinode番号は「ls -il」コマンドで確認することが出来ます。


ハードリンクを作成するにはlnコマンド(書式:ln 元ファイル リンクファイル)を利用します。
例)File1のハードリンクをFile2として作成する場合


File2はFile1のハードリンクのため、inode番号が同じです。ただこの時点で、どちらがリンクファイルであるかの区別は無くなります。
この状態でFile1を削除しても、File2が実体にリンクしているため実体は残ります(削除されません)。File2も削除し、ハードリンクが0になると、実体がはじめて削除されます。

ハードリンクの制限として以下の2点があります。
1. ディレクトリのハードリンクは作成できない
2. 異なるファイルシステム(パーティション)にハードリンクを作成できない

1の制限は循環ディレクトリの作成を防ぐためです。例えば、testという1ユーザーしか利用しない環境で「/home」を「/home/test」にハードリンクしてしまうと、「/home/test」の「/home」が「/home/test」に置き換えられるため、「/home/test/test/test/...」と無限に続く循環ディレクトリができてしまうことになります。

2の制限はinode番号が各ファイルシステム毎に別々に管理されているためです。異なるファイルシステムではinodeの利用状況が異なるため、全く同じinodeを割り当てて正しく参照できる保証がありません。

これらの制限はシンボリックリンクを使う事で解決できます。

【シンボリックリンク】
シンボリックリンクとは、Windowsでのショートカットのようなもので、元ファイルの場所を指し示すリンクの事です。
シンボリックリンクが持っている情報は「元ファイル(ディレクトリ)がどこにあるのか」というパス情報のみです。



上図のFile2はFile1への単なるショートカットです。
File1を削除すると(他に同じinode番号を持つハードリンクが無ければ)、ファイルの実体は削除されますが、File2は残ります。ただその場合、File2にアクセスすると、リンクしているFile1が無いためエラーになります。

シンボリックリンクを作成するにはlnコマンドに「-s」オプションを付加して作成します。(書式:ln -s 元ファイル リンクファイル)
例)File1のシンボリックリンクをFile2として作成する場合


File1とFile2ではinode番号が違う事が分かります。
また、File2にはシンボリックリンクを示す「l」がパーミッションの先頭に表示されています。ファイル名を示す欄では、File2はFile1のシンボリックであることが分かります。
上に戻る

ハードリンクはディスク容量を消費しない?

公開日 2024/06/21

最強WEB問題集 LPIC Lv1-101(Ver5.0) 問題ID : 3701において、
「ハードリンクはディスク容量を消費しない」という選択肢が正答に含まれていますが、ハードリンクのメタデータ(ハードリンク名や参照先iノード番号)の分だけディスク容量を消費するのではないでしょうか。

2024/06/22 17:38

これと同じ話ですか?
https://mondai.ping-t.com/g/posts/1398


コメント

h harmo

2024/06/22 18:48

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

a arashi1977

2024/06/22 23:02

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

a arashi1977

2024/06/23 09:03

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

h harmo

2024/06/23 15:55

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

a arashi1977

2024/06/23 21:22

そうなのですか! ハードリンクがすでにあるファイル(実データ)への別名による参照だと理解していたので、どちらもファイルだと思っていました。 ーーー $ 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ではすべてのリソースがファイル」という概念を昔学んだのが根本にあったので「ハードリンクもファイル」という認識でいましたが、今は変わっているのですかね。認識を改めねば。

a arashi1977

2024/06/24 07:31

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

h harmo

2024/06/24 10:11

次のページに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とファイル名のマッピング情報の追加、という程度の違いなのかもしれません。

a arashi1977

2024/06/24 23:23

ありがとうございます。クリアにしたい部分がクリアにならなかったのでお尋ねするのですが > という部分等から、 > ・通常ファイルとは一意の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なのか、それとも別の情報のことなのでしょうか? (最初のコメントの「固定サイズのメタデータ格納用ファイル」の理解に必要な情報である認識です)

h harmo

2024/06/25 01:14

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)。

a arashi1977

2024/06/25 08:22

ありがとうございます。 (いただいた回答から、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とかでは役不足かなと思いますので、期待するレベルに合う別の認定資格をお探しになった方が良いかもしれません。

a arashi1977

2024/06/25 08:30

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

h harmo

2024/06/25 20:01

>>このレベルで想定する運用観点で考えれば、この問題も私の認識でも「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の方が監修されていたり、全て過去問として出題された実績があるということでしょうか。一般的にはこのようなサービスは資格団体と独立していて、それが資格試験全体のレベルを示す証明にはならないと思うのですが…

a arashi1977

2024/06/26 00:21

この問題というか、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.

h harmo

2024/06/26 13:19

疑問を呈したのは、 >>もし「メタデータも考慮しないのか!」とレベルの低さを嘆かれるようであれば、 >>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の試験範囲であるか否かに移っていますが、これに関しても、 ・ハードリンクやエントリ、ディレクトリのディスク容量消費に関する記述はない という結論でいいのではないでしょうか。(ファイルシステムに依存する部分があるので書いてない可能性もある)

a arashi1977

2024/06/27 07:59

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

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?