アカウント名:
パスワード:
少し補足すると、最近私用で可動部分を一切用いない、1UのハイトでハーフサイズのPC/AT機を見せてもらいました。Linuxが載っていてflash ATAでbootするのですが、どう頑張っても256MBの壁があるためやはり/binや/sbinは厳しいそうです(機能拡張のためにHDDを載せるオプションもあるそうで)。
容量がきびしい環境では crunched binary にすれば? という気がするんだが…
それはさておき、/ と /usr を別パーティションにする習慣が一部にあるためにライブラリの置き場が /usr/lib と /lib の2箇所になってしまうのがなんかいやん。
使い方によっては、/varだけでなく/var/spoolや/var/mailも別にしてしまうこともありますね。/var/spool以下はinodeを大量に使う可能性がありますし(mailやnewsをため込む場合)、/var/mailはファイルサイズが太る恐れがあります。
うちの場合、/var/spoolで何度かinodeが足りなくなったため、現在はinode数を4倍に増やしたfilesystemを使っています。
/var が別パーティションゆーんは当然。
まあ同じアーキテクチャの同じ OS の同じバージョンのマシンを何台も管理してれば / と /usr をわけるとちょっとは楽なんでしょうけど。その程度のことでしょ? / で変更されやすいのは /etc ぐらいだろうし、/bin /sbin の更新頻度と /usr/bin /usr/sbin の更新頻度が違
boot fdとかだと、crunchかつ{g,b}zipしても1.44MBに収まるかどうかという厳しい条件になることもあります(そのたびに何を削るかでもめる)。こういう場合は/libが別建てになると助かります。
もしPC/ATが早い段階で素直にOpenBootを使っていて、どんな計算機でも気軽にnetbootできる状況ならばSolarisよろしくいきなり/、/var、/usrをmountできて一番楽なんだけどなぁ...(恨めしい)
crunchで残る問題として、crunched binary全体をaddress spaceにmapしなければならないことがあります。crunchが大きくなれば必要なpage数も増えます。中には実際には実行されないにもかかわらずmapされてしまうpageもあるでしょう。
こんな時にshared objectが使えれば、実行しないtext、読まないdataには一切pageを使う必要がありません。pmapを初めとするvm metadataを切り詰めた状態でも動くものができる可能性があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
i386でも恩恵あり (スコア:2, 参考になる)
少し補足すると、最近私用で可動部分を一切用いない、1UのハイトでハーフサイズのPC/AT機を見せてもらいました。Linuxが載っていてflash ATAでbootするのですが、どう頑張っても256MBの壁があるためやはり/binや/sbinは厳しいそうです(機能拡張のためにHDDを載せるオプションもあるそうで)。
Re:i386でも恩恵あり (スコア:0)
容量がきびしい環境では crunched binary にすれば? という気がするんだが…
それはさておき、/ と /usr を別パーティションにする習慣が一部にあるためにライブラリの置き場が /usr/lib と /lib の2箇所になってしまうのがなんかいやん。
別パーティションにする習慣が一部にある (スコア:3, 興味深い)
ものだと思いました。
BSDの歴史において、/と/usrを別にするのは伝統であり、
暗黙の了解事項だと思って今まで生きてきました。
PDPあたりのディスクの制限であったり、シングルユーザモード
で走行するための最小環境であるために、歴史的に/は小さく
作られてきたのだと思います。
また、ディスクレスWSなるものが導入された時、/は個々のWS
固有のデータを、/usrは共有可能な領域でリードオンリーとされた
こともありました。
バックアップ時は、/はシステムの一時ファイルを保持したり、
システム設定ファイルが編集修正されるため、バックアップ頻度
を多くし、/usrは新ソフトを追加しない限り変更はないものとし、
頻度を下げることが出来る領域だとも思っていました。
僕は今もそう思って、多くのサーバを今でも管理しています。
ひとによって環境は違うのでしょうが、僕にはちょっと驚きの表現
でした。
Re:別パーティションにする習慣が一部にある (スコア:1)
むしろ/が小さすぎて、システムアップグレード時に溢れちゃったりすると悲しかったり(/kernel.oldと/modules.oldを削除してなんとかなりましたが)。
FreeBSDあたりはAを押せばお任せでパーティションを切ってくれるのでそのまま使ってますが、linux系のシステムはそういうのが無いので、/とswapだけ作ってインストール、なんてこともよくやります。
はじめて使うシステムなどですと、どこがどれだけ食うか把握できないので、この方が安全なこともあったりしますね。debianをはじめていれた時、FreeBSDしか知らなかったもので、/varに30Mしか割り振らずに悲しい思いをしました。debianは/varを酷使しますね。今では1Gあっても足りないと思ってます^^;;
Re:別パーティションにする習慣が一部にある (スコア:0)
/tmpはmfsするもんだし。
#ちなみにNetBSDはcronで /var/backupにcvsで/etcの各種設定ファイルを保存してくれる。便利。
なもんで/に一時ファイルとか言われるとなんか気持ち悪い。
Re:別パーティションにする習慣が一部にある (スコア:1)
使い方によっては、/varだけでなく/var/spoolや/var/mailも別にしてしまうこともありますね。/var/spool以下はinodeを大量に使う可能性がありますし(mailやnewsをため込む場合)、/var/mailはファイルサイズが太る恐れがあります。
うちの場合、/var/spoolで何度かinodeが足りなくなったため、現在はinode数を4倍に増やしたfilesystemを使っています。
Re:別パーティションにする習慣が一部にある (スコア:0)
/var が別パーティションゆーんは当然。
まあ同じアーキテクチャの同じ OS の同じバージョンのマシンを何台も管理してれば / と /usr をわけるとちょっとは楽なんでしょうけど。その程度のことでしょ? / で変更されやすいのは /etc ぐらいだろうし、/bin /sbin の更新頻度と /usr/bin /usr/sbin の更新頻度が違
Re:別パーティションにする習慣が一部にある (スコア:1)
/etcを/と別パーティションにしても問題ないもんでしょうか?
#fstabのある/etcが別だと、mountするために見に行く先が
#mount後まで見えない、なんてまぬけな話になりそうな気が・・・。
#・・・間違ってますかね(汗)?
---- redbrick
Re:別パーティションにする習慣が一部にある (スコア:0)
Re:別パーティションにする習慣が一部にある (スコア:0)
その他は /etc マウント前の /etc に
/etc/fstab, /etc/passwd, 他が最小限あればどうにかなるかな。
NetBSD あたりなら mount_union でいけそう?
Re:別パーティションにする習慣が一部にある (スコア:0)
#自分でrcをぐちゃぐちゃと弄り回すってのは黒魔術だよな。
/を別にするのは/etcを(単体で別にすることはできないから/ごと)別にして/usrを(同一アーキテクチャで)共通にしたいからですよね。
#/usr/shareも(異アーキテクチャで)共通にしたいな。
こういう人は「/varが別パーティションとゆーんは当然」です。
でも「変更さ
Re:別パーティションにする習慣が一部にある (スコア:0)
/別にしたいのはマシンごとにカーネルを別にしたいからっていう理由も考えられますね。
Re:i386でも恩恵あり (スコア:1)
boot fdとかだと、crunchかつ{g,b}zipしても1.44MBに収まるかどうかという厳しい条件になることもあります(そのたびに何を削るかでもめる)。こういう場合は/libが別建てになると助かります。
もしPC/ATが早い段階で素直にOpenBootを使っていて、どんな計算機でも気軽にnetbootできる状況ならばSolarisよろしくいきなり/、/var、/usrをmountできて一番楽なんだけどなぁ...(恨めしい)
省メモリも可能か? (スコア:1)
crunchで残る問題として、crunched binary全体をaddress spaceにmapしなければならないことがあります。crunchが大きくなれば必要なpage数も増えます。中には実際には実行されないにもかかわらずmapされてしまうpageもあるでしょう。
こんな時にshared objectが使えれば、実行しないtext、読まないdataには一切pageを使う必要がありません。pmapを初めとするvm metadataを切り詰めた状態でも動くものができる可能性があります。
Re:i386でも恩恵あり (スコア:0)