FreeBSD 10.3 RELEASE - インストール - マウントポイントの作成

クラウディア 
 この項、前項の続きですが、パーティションの入力で「Auto (UFS)」を選んでいれば本項は飛ばしてください。
1. マウントポイントの作成

1. マウントポイントの作成

 前項で、FreeBSD に割り当てる領域を設定していれば、その領域を選択状態にし [C] でマウントポイントを作成していきます。
「FreeBSD 10.3 RELEASE」-「Partition Editor」

 FreeBSD に割り当てる領域を設定して [OK] を押下していきます。
 前項で「Manual」を選んだもののここで Cancel して [A] で自動的にマウントポイントを割り当てることもできます。

「FreeBSD 10.3 RELEASE」-「Partition Editor」「Add Partition」

 マウントポイントの設定方法は、管理者の設計思想によるものですが、わたしの設定方法は、ハンドブックでおすすめしている方法とは異なりますが、参考までに紹介しておきます。例題で紹介しているのは仮にディスクの全領域を 40GB とした場合です。

パーティションタイプサイズマウントポイント
freebsd-boot512K
freebsd-ufs 4GB /
freebsd-swap後述
freebsd-ufs 4GB /home
freebsd-ufs 4GB /var
freebsd-ufs 残りの全領域/usr
 マウントポイントの説明
boot領域
 boot 用の領域は、起動用ディスクの場合、ルートラベルを作成したときに自動的に割り当てられます。

ルートラベル /
 ディスク内のすべてのディレクトリのルートになります。
 細かくマウントポイントを分けない場合は、ここに全領域を割り当てることも可能です。

スワップラベル swap
 実装メモリの2倍以上のサイズを目安に割り当てます。

ユーザラベル /home
 おもにログインユーザ用の領域です。

変更情報ラベル /var
 ログファイル等の領域です。

システムユーザラベル /usr
 実行モジュールやライブラリ用の領域です。
 経験則では「/」「/home」「/var」「/usr」の比率を 1:2:2:残り くらいにしておくと効率よくディスクを使用できます。  もちろん用途により、後のことを考えて容量の割り当てを行ってください。  ラベル名はつけないことも可能ですが、ディスクを移行するときに便利に使えるようになるらしいので、わかりやすくてそれぞれの領域がユニークになるような名称をつけてください。  マウントポイントは [C] を押下して作成します。  Type、Size、MountPoint にそれぞれ値を入力して、[OK] にカーソルをあてて [Enter] を押下します。  下記は、120 GB のディスクで [Auto] で作成した例です。
「FreeBSD 10.3 RELEASE」-「Partition Editor」「Auto 設定」

 作成できたら、Finish で [F] を押下します。
 確認画面が出てきますので、問題がなければ [Commit] にカーソルをあてて [Enter] を押下します。

「FreeBSD 10.3 RELEASE」-「Confirmation」

 自動的にディスクがフォーマットされ、システムファイルがインストールされます。
 進行状況を示す画面が以前に比べてほんの少しカラフルになっています。

「FreeBSD 10.3 RELEASE」-「フォーマット中」

Tips
 ユーザ用のディレクトリ名が /home であったり、/usr であったり、慣れないひとにはわかりにくいかと思います。面白い記事をみつけましたので、記載しておきます。(http://d.hatena.ne.jp/ytakano/20100715/1279219401 の孫引きになります)

なぜ,/var や /etc が /etc や /cfg というディレクトリ名ではないのか?
Unixを使っていると,/usr が全然ユーザー用じゃなくどう見てもシステムのための物だったり,/etc が事実上設定ファイル置き場となっていたり,/var がログファイル置き場となっていたりと,名が体を現していなくて奇妙な感覚を覚える.もっと分かりやすい名前の付け方があったんじゃないかと,Unixユーザーならば誰もが思うはずだが,これに対する解答がredditに投稿されており,その内容が非常に面白かったので,軽く翻訳してみた.
		
Anyone know why /var and /etc weren't named something like /etc and /cfg?
http://ja.reddit.com/r/linux/comments/cpisy/anyone_know_why_var_and_etc_werent_named/c0ua3mo
昔々,システム7が使われていてUnixがピカピカで新しかった頃,/bin にはバイナリファイルを,/usr にはユーザーのホームを,/libにはライブラリを,その他は /etc 以下に置くことが決められた.これは,"エトセトラ"が意味することそのものであった.その後,アプリケーションには設定ファイルが必要となり,それらは独自の階層を持つディレクトリを作り置いていた.しかし,ユーザーはそのファイルを見つけにくいと文句を言った.彼らは,全てのファイルが /etc というひとつのディレクトリに置かれることを望んだのだ.

その後しばらくたち,ユーザーは自分でコンパイルしたバイナリを /bin 以外の他の場所に起き始めた.やがて,システムが提供するバイナリと混同するのを避けるため,それらは /usr/bin 以下に置かれることになった.

/usr はユーザーによってインストールされたものが置かれる標準ディレクトリとなり,ますます,いろいろなモノがインストールされるようになった.しかし,それらの多くは,システムによって利用されるようになってしまった.そのため,人が使うディレクトリと,システムが使うディレクトリを分離するため,ユーザーのホームディレクトリは,/home に移された.

/var はディスクレスのワークステーションから生まれた.これらは,ディスクなしで起動し,カーネルはNFS経由でロードされ,/ と /usr ファイルシステムはリモートのサーバから,読み込み専用のファイルシステムとしてマウントされた.すべてのオペレーティングシステムのファイルは,すべてのワークステーションで同一であるので,これは納得出来ることであった.それらワークステーションは同じ共有ファイルシステムをマウントするのだ.しかし,依然として,ワークステーションが読み書き可能な独自のファイルシステムが必要であったので,ワークステーション間で違う変数(variable)を保存するためのファイルシステムとして,/var が生まれたのだ.

ああ,私も歳をとったものだ.
		
 A long long time ago, in the System 7 days when Unix was shiny and new it was decided that in /bin would go the binaries, /lib the libraries, in /usr would go the users' homes and everything else would go in... /etc. That's what it meant back then, "et cetera". When applications needed configuration files they often put them in their own additional hierarchies but the users complained that trying to find those files was annoying; they wanted all those files in one directory and /etc was the only place that fit the bill.

 After a while the users started compiling their own binaries and they needed to put them someplace other than /bin, so as not to confuse them with the system ones, so that's where /usr/bin came from.

 Because /usr became a standardish place which could be used for user-installed stuff, it was more and more populated with things started by users but a lot of those were adopted by systems, so after a while users' homes were moved into /home to segregate the humans from another directory known for system stuff.

 /var was born out of the needs of diskless workstations. Into those days, you could boot a machine without a disk; they would load their kernel over NFS and then mount the / and /usr filesystems read-only from a central remote server. It made sense since all the operating-system files were identical on all workstations, so they all mounted the same shared filesystems. But you still needed at least one filesystem where the workstations could read & write their own files separately since this stuff was "variable" between workstations, /var was born.

 Boy I'm old.
		
 この項、続きます。
ハイスピードプラン