アカウント名:
パスワード:
T/O
*BSD の優位性というより UNIX の基礎な気がします。
/, /boot しか切られていないサーバを稀に見つけますが、/var のログがパンクして login できなくなるとか怖くなります。
ファイルの数にしたって一つのディレクトリに数万ファイルで ls は実用に耐えません。bash の補完も「何万ファイルあるけど、マジで？」と聞いてくるまでに数時間かかります。
FreeBSD は fsck に関してはBackground fsck [wikipedia.org]があるので、優位と言えば優位なのかも知れません。Solaris の恩恵を受けて ZFS を利用すれば、もっと色々と便利なのかも知れません。
Linux も LVM でパーティションの容量管理は比較的容易になったので、パーティショニングは昔のように千里眼である必要はありません。
昔のUNIXにありましたね。/があふれると、挙動が不安定になるやつ。だから、/var, /tmp, /homeは/と同じにするんじゃない、と。
他の方が書いている通り、最近のは無いと思いますよ。でも、慣例で分けてしまいます。VM上のテスト環境で、お任せモードでのインストールをするときだけ/の単発が出来上がりますが。
> /, /boot しか切られていないサーバを稀に見つけますが、> /var のログがパンクして login できなくなるとか怖くなります。
単一パーテーションのDebian Lenny で確認しました。領域がパンパンになるまで一般ユーザでファイルをたくさん作りましたが、スーパーユーザになると予約領域が使えるらしく、もう少し沢山書き込みができました。
続いて、スーパーユーザでも書き込めなくなるまで埋めましたが、コンソールログインには支障ありませんでした。
# 流石に再起動するとカーネルパニックになったけどw
> /var のログがパンクして login できなくなるとか怖くなります。
どのファイルシステムがfullになっても、ログインが出来なくなることはないと思いますよ?ログは残らないですが。
FreeBSD で立てた Web Server で log lotation の予想を超えて貯まったために /var 130% とか起こしてしまい、sshd すらスワップアウトされていたらしく login までに数分かかったことならあります。その間にも /var が膨らんでいたので、かなり危なかったかもしれません。そんな状況でよく動くよなと同僚が感心してました。
> FreeBSD で立てた Web Server で log lotation の予想を超えて貯まったために /var 130% とか起こしてしまい、
デフォルトだと予備領域が10%なので、さすがに110%を超えないんじゃないですかね。
> sshd すらスワップアウトされていたらしく login までに数分かかったことならあります。
数十分以上ってのもありますね。メモリ不足やプロセステーブルがあふれた時などは、特攻隊コマンドが役に立ちます。
> exec su
パスワード間違えると、本当にそのままサヨナラです。
minfreeのdefaultは8%ですが……FreeBSDの話ですよね?$ grep MINFREE /sys/ufs/ffs/fs.h * MINFREE gives the minimum acceptable percentage of filesystem#define MINFREE 8
background fsckはまったくスケーラビリティがなく、起動前のsnapshotsにinode数に比例した時間がかかります。
十億ものファイルを持つファイルシステムをfsck -Bなんかしたら丸1日くらいピクリとも動かないんじゃないですかね。
background fsck前提のファイルシステムはnewfs時に思い切りinodeの数を減らしましょう。減らせば減らすほどsnapshotsが速くなります。そうしないと使えたもんじゃありません。なんというかその、使わないのが一番です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
ここで*BSDの優位性をアピールっ！ (スコア:0)
T/O
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
*BSD の優位性というより UNIX の基礎な気がします。
/, /boot しか切られていないサーバを稀に見つけますが、
/var のログがパンクして login できなくなるとか怖くなります。
ファイルの数にしたって一つのディレクトリに数万ファイルで ls は実用に耐えません。
bash の補完も「何万ファイルあるけど、マジで？」と聞いてくるまでに数時間かかります。
FreeBSD は fsck に関してはBackground fsck [wikipedia.org]があるので、
優位と言えば優位なのかも知れません。
Solaris の恩恵を受けて ZFS を利用すれば、もっと色々と便利なのかも知れません。
Linux も LVM でパーティションの容量管理は比較的容易になったので、
パーティショニングは昔のように千里眼である必要はありません。
Re:ここで*BSDの優位性をアピールっ！ (スコア:2)
昔のUNIXにありましたね。/があふれると、挙動が不安定になるやつ。だから、/var, /tmp, /homeは/と同じにするんじゃない、と。
他の方が書いている通り、最近のは無いと思いますよ。でも、慣例で分けてしまいます。VM上のテスト環境で、お任せモードでのインストールをするときだけ/の単発が出来上がりますが。
-- gonta --
"May Macintosh be with you"
Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 興味深い)
> /, /boot しか切られていないサーバを稀に見つけますが、
> /var のログがパンクして login できなくなるとか怖くなります。
単一パーテーションのDebian Lenny で確認しました。
領域がパンパンになるまで一般ユーザでファイルをたくさん作りましたが、
スーパーユーザになると予約領域が使えるらしく、もう少し沢山書き込みができました。
続いて、スーパーユーザでも書き込めなくなるまで埋めましたが、コンソールログインには支障ありませんでした。
# 流石に再起動するとカーネルパニックになったけどw
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
> /var のログがパンクして login できなくなるとか怖くなります。
どのファイルシステムがfullになっても、ログインが出来なくなることはないと思いますよ?
ログは残らないですが。
Re: (スコア:0)
FreeBSD で立てた Web Server で log lotation の予想を超えて貯まったために /var 130% とか起こしてしまい、
sshd すらスワップアウトされていたらしく login までに数分かかったことならあります。
その間にも /var が膨らんでいたので、かなり危なかったかもしれません。
そんな状況でよく動くよなと同僚が感心してました。
Re:ここで*BSDの優位性をアピールっ！ (スコア:1)
> FreeBSD で立てた Web Server で log lotation の予想を超えて貯まったために /var 130% とか起こしてしまい、
デフォルトだと予備領域が10%なので、さすがに110%を超えないんじゃないですかね。
> sshd すらスワップアウトされていたらしく login までに数分かかったことならあります。
数十分以上ってのもありますね。
メモリ不足やプロセステーブルがあふれた時などは、特攻隊コマンドが役に立ちます。
> exec su
パスワード間違えると、本当にそのままサヨナラです。
Re: (スコア:0)
minfreeのdefaultは8%ですが……FreeBSDの話ですよね?
$ grep MINFREE /sys/ufs/ffs/fs.h
* MINFREE gives the minimum acceptable percentage of filesystem
#define MINFREE 8
Re:ここで*BSDの優位性をアピールっ！ (スコア:1, 参考になる)
background fsckはまったくスケーラビリティがなく、
起動前のsnapshotsにinode数に比例した時間がかかります。
十億ものファイルを持つファイルシステムをfsck -Bなんかしたら
丸1日くらいピクリとも動かないんじゃないですかね。
background fsck前提のファイルシステムは
newfs時に思い切りinodeの数を減らしましょう。
減らせば減らすほどsnapshotsが速くなります。
そうしないと使えたもんじゃありません。
なんというかその、使わないのが一番です。