X
*BSDがLinuxに勝っている点を何とか挙げていくスレ
0001名無しさん＠お腹いっぱい。
2006/11/18(土) 18:22:42
万が一あったら書き込んでください
0010名無しさん＠お腹いっぱい。
2006/11/21(火) 02:43:36
Fin.
0012名無しさん＠お腹いっぱい。
2006/12/07(木) 22:45:38
>>1
そんなの存在しない
0013名無しさん＠お腹いっぱい。
2006/12/07(木) 23:18:54
ファイルシステムにsoftupdate。copy on writeとほぼ同じ。
ext3の様な単純なジャーナリングファイルシステムよりも優秀。
0014名無しさん＠お腹いっぱい。
2006/12/08(金) 07:00:00
ブランド女の振る舞いの如く、玄人振れるとこ
0015名無しさん＠お腹いっぱい。
2006/12/08(金) 07:32:49
「Linuxを使って居ます」と言っても「モー娘の名前を全部言えます」
程度の威力しかないが、「FreeBSDを使って居ます」と言えば
「美空ひばりのレコーディングに参加した演奏家の名前を全部言えます」
ぐらいの威力がある。NetBSDやOpenBSDだったら、凄過ぎて、
「それ何？」で終ってしまう事も多いから御用心
0016名無しさん＠お腹いっぱい。
2006/12/08(金) 23:05:42
デーモン君のきもさ
0017名無しさん＠お腹いっぱい。
2006/12/08(金) 23:08:25
あのペンギンも結構キモいからなあ
死体画像なみ
だからその点は甲乙つけがたい
0018名無しさん＠お腹いっぱい。
2006/12/08(金) 23:19:02
>>13
同感
ext3 (その他のLinuxのファイルシステム使ってません)が、
ファイルアクセスすればするほど、メモリ・キャッシュ取りすぎ！
ここに何か欠陥隠しをしてるんだろうけど？
プロセス全体に負荷がかかるは、やめて欲しいな。

・・・専用機だから、仕方がない。そんな使われ方ですよ。
高負荷を与えて、ssh,telnetも出来ないのは頂けない。
0020名無しさん＠お腹いっぱい。
2006/12/15(金) 00:57:30
>>19
ここを説明してくれない？
空き容量、５Ｇはある、そこに４０Ｇのファイルを作ると宣言する。
Linuxは、どうぞと返事する。

さて、それを信じて書き込むとエラーだって。
ＯＳを信じるのが、バカってことか？

どうにかしてくれよ、Linuxだろ！

BSD派は確実に確保しようとする。
処理時間掛かってもね。確実に確保したいから。
確認してＯＫってＯＳが言って、後で訂正は面倒だよ。

エラー処理のコードを書くのが、面倒なんです。

では、意味ある回答を望みますw









0022名無しさん＠お腹いっぱい。
2006/12/15(金) 05:14:17

　　 ／￣￣＼
　／　　 _ノ　　＼
　|　　　 （ ●）（●）
.　|　　　　 （__人__）
　 |　　　　　｀ ⌒´ﾉ
.　 |　　　　　　 　 }　　ミ　　　　　　　　ﾋﾟｺｯ
.　 ヽ　　　　　 　 }　ミ　 ／＼　　,☆＿＿__
　　 ヽ　　　　　ノ　　　　＼　 ＼ ／　　 　　＼　>>20
　　　/　　　 く　　＼.　　／＼／　─　 　 ─　＼
　　　|　　　　　`ー一⌒)　 ／ 　 （●） 　（●）　 ＼
　 　 |　　　　i´￣￣￣ ＼ |　 　 　 （__人__）　　 　 |
　　　　　　　　　　　　　　　＼＿　　 ｀ ⌒´　 　　／
　　　　　　　　　　　　　　　　／　　　 　　　　　　＼
0023名無しさん＠お腹いっぱい。
2006/12/16(土) 13:20:29
BSD終わってるな
0026名無しさん＠お腹いっぱい。
2006/12/17(日) 11:08:03
経験則的に、同じマシン2台あってLinuxとFreeBSDをそれぞれ入れて同負荷をかけた場合
（タスクは一般的なWeb兼メールサーバ）、先にマシンが死ぬのはLinuxじゃないかという気がします。
1年以内にHDDが死ぬのは決まってLinux入れた方。
0028名無しさん＠お腹いっぱい。
2006/12/17(日) 13:59:44
自由自由うるさい犬っころよりもっと自由なライセンス
0030名無しさん＠お腹いっぱい。
2006/12/18(月) 14:42:12
厨房率が低いのは勝ってるとこかもしれないけど


それって 間口が狭い＝先が暗い って事だよもん？
0034名無しさん＠お腹いっぱい。
2006/12/22(金) 17:15:30
ウニ板のスレに限っては
真性なのか釣りなのかジョークなのかはかりかねて手出ししにくい

0036名無しさん＠お腹いっぱい。
2007/01/06(土) 04:45:18
Linux って SYNC でディスクに書けと言っても、書き終わる前にリターンするとかだったけ。

あと
ttp://www.sodan.ecc.u-tokyo.ac.jp/~kei/sched/
とか見てると、スケジューラの作りもいい加減そうだし…（2.4 のころの話みたいだけど）

ちょっとでも軽くする為に、機能がちょっとぐらいいい加減でもいいというのが感じられて、
正直そんな OS は使いたいとは思わない。
0043名無しさん＠お腹いっぱい。
2007/02/18(日) 00:27:11
m:nでうまくいかなかった上に、バカにしていた方向にあとから
方針転換するのはカッコ悪いよねえ
0044名無しさん＠お腹いっぱい。
2007/02/18(日) 07:12:43
*BSD(特にFreeBSD)では何度となく繰り返された道じゃないか
結果Linuxの後追いになってしまうという
0045名無しさん＠お腹いっぱい。
2007/03/01(木) 15:19:00
ttp://jeffr-tech.livejournal.com/6268.html#cutid1

世界中でどれだけのリソースが無駄になってるかと想像すると怖くなるな(w
0046名無しさん＠お腹いっぱい。
2007/03/02(金) 15:48:11
「Linux が好き」という人より「FreeBSD が好き」という人の方が多いらしい。

ttp://www.sucks-rocks.com/rate/windows/linux/os+x/freebsd
0047名無しさん＠お腹いっぱい。
2007/03/05(月) 18:19:02
>>46
LinuxからFreeBSDに移行した友人がいます。
彼の話ではどのパッチを当てるのがいいとか
Linuxは問題が複雑だけれども、

FreeBSDのほうが瑣末なことにわずわらされ
ないからとのことでした。
0048名無しさん＠お腹いっぱい。
2007/03/05(月) 19:00:44
Linuxでは「○○がしたい？それならこのパッチ当ててくれ。」って事が多いんだよな。
FreeBSDは最初はパッチでもいつの間にか正式に取り込まれてるから楽だよな。
0050名無しさん＠お腹いっぱい。
2007/03/08(木) 16:29:45
会社的な事情でGPLを避けたいときに*BSD使うこと多い
0054名無しさん＠お腹いっぱい。
2007/03/09(金) 23:17:29
>>36
え？そうなの？
じゃぁ、
sync; sync; reboot の２回のsyncは意味がないってことか
0055名無しさん＠お腹いっぱい。
2007/03/09(金) 23:20:36
ports collection がある限り、野良ビルドはほとんどないな。
Linux 使ってると、野良ビルドばかりするはめになる。
0058名無しさん＠お腹いっぱい。
2007/03/09(金) 23:49:15
そもそもソースの配布元が、FreeBSDでもそのままビルドできるように
configureとかも含めて配布しているのに、
なぜportsのローカルなpatchを当てなければならないのか?

オリジナルに忠実にビルドするには野良ビルドが基本。
portsなんか使わない。
0059名無しさん＠お腹いっぱい。
2007/03/10(土) 00:59:35
Debian使ってるけど、こんなスレ読んでたらFreeBSDとか試してみたくなった。
6.2と5.5ならどっちがお薦めですか？

Linuxのファイルシステムの方がディスクの寿命が短くなるって本当？
0061名無しさん＠お腹いっぱい。
2007/03/10(土) 01:19:35
>>59 5系は暗黒神話です
ディスクの寿命云々は聞いたこと無い。

ports使う理由は依存関係とそれに関連して共有ライブラリ
バージョン間互換性の問題が大きいと思う。

特定のアプリケーションしか使わないならどうでもいいん
じゃない? 自分で面倒見れるなら問題ない。
0062名無しさん＠お腹いっぱい。
2007/03/10(土) 01:41:42
>>60
>>61
レスありがとうございます。取り合えず6.2落として、来週にでも余ってるPCに入れて遊んでみます。
ディスク云々と書いたのは>>26に経験則的に〜っていうのがあったもので、本当かなぁって思ったからです。
空きPCで遊ぶのでどうでもいい問題ですけどw
0063名無しさん＠お腹いっぱい。
2007/03/10(土) 12:31:51
STABLE用のportsから作られたpackagesは、
内容が逐次更新されているのに、元ソースのバージョン番号が同じなら、
packagesのバージョン番号も同じ=packagesのファイル名が同じ、
で、これが非常に困る。
同じファイル名なのに中身が違っていて、しかも、
ライブラリの依存関係が変更されていて正常に動かないことがある。
packagesに、なぜ枝番を付けないんだろうか?
というわけで、ports/packagesを使ってもライブラリの依存関係は
全然解決にならないよ。
0064名無しさん＠お腹いっぱい。
2007/03/10(土) 13:32:06
>>54
> sync; sync; reboot の２回のsyncは意味がないってことか

もっと酷い話だと A, B という順に書いて B が先に書かれるケースがある > Linux
だから Oracle/Linux もある種のロールバックを保証してなかったはず。
0067名無しさん＠お腹いっぱい。
2007/03/11(日) 00:05:07
ところでハードディスクにキャッシュがある場合、いちいちキャッシュをフラッシュ（やったっけ？）しないと
確か書き込み手順が守られないはずだけど、*BSD の場合はどうなってる？
まあ Linux は聞こうとも思わないけど…。
0068名無しさん＠お腹いっぱい。
2007/03/12(月) 10:13:25
>>67
softupdate はバッファ内の順序認識でそれを保証してる。
つまり「Bの前にAが書かれないといけない」→「Aの書き込み成功が無いとBは書かない」
こういった順序関係の無いデータはなるべく平行して(一度に)書こうとする。

まぁLinuxはアレだ。知りたい奴はぐぐってくれ(w
0071名無しさん＠お腹いっぱい。
2007/03/12(月) 15:27:42
ttp://www.unixuser.org/~euske/doc/openssh/theointerview2001.html

> これはファイルシステムをできるかぎり高信頼性には
> するけれど、一般的なオペレーションの速度を犠牲に
> する。たくさんの古い CSRG のテクニカルレポートを
> みれば、なぜこれがファイルシステムを安全にするか
> はっきり説明しているよ (そしてぼくは Linux コミュ
> ニティはこれに対してまったく無知だと思うね。彼ら
> はそろそろ ext2fs のような完全に非同期なファイル
> システムは危険だということを認めるときだ。Linux
> 管理者がすでにそのことを知っていなければの話だが)。
0072名無しさん＠お腹いっぱい。
2007/03/12(月) 17:52:01
怠け者のことは怠け者と呼ぶべきだし
マニュアルページを読まない奴のことは負け犬と呼ぶべきだし
0074名無しさん＠お腹いっぱい。
2007/03/12(月) 19:31:47
>>68
softupdateは外づけRAIDユニットの中のキャッシュの
データの書き込み順序も保証してくれるのかにゃ？
0075名無しさん＠お腹いっぱい。
2007/03/12(月) 19:44:57
RAID との責任分担を考えれば自明な気がするけど、仮
に softupdate で面倒見れないならどうやっても駄目な
んじゃ?
0077名無しさん＠お腹いっぱい。
2007/03/12(月) 21:05:37
とりあえず RAID も ata もコントローラに flush リク
エスト出してるコードは見つけた。今度いつ呼ばれるか
探してみる（抽象化レイヤがややこしい…）。
0080名無しさん＠お腹いっぱい。
2007/03/13(火) 10:26:42
すまん、ギブ。とりあえず flush してるとこ。

/usr/src/sys/dev/ata/ata-disk.c:ad_dump
/usr/src/sys/dev/ata/ata-raid.c:ata_raid_dump

共に長さ 0 の dump で flush の意味になってて、
attach 時に *->disk->d_dump に設定される（ioctl の
方は追い掛けきらなかった）。

トランザクションの終りはこの辺りかなと思うけどよく
わからない。

/usr/src/sys/kern/subr_devstat.c:devstat_end_transaction
0084名無しさん＠お腹いっぱい。
2007/03/13(火) 11:55:13
vfs_bio.c:bufwrite がそれかな。非同期だとバックグ
ラウンドで、同期だとその場で I/O オペレーションの
終了を待ってる。

デバイスが「write-I/O が終わった」というなら、それ
以降の責務はデバイスが持つというスタンスじゃない?
0085名無しさん＠お腹いっぱい。
2007/03/13(火) 12:24:28
geomでファイルシステム上に作ったファイルをmountして
フォーマットしたときに、「write-I/Oが終わった」という
デバイスはどれになるの?
geom?HDD?
0086名無しさん＠お腹いっぱい。
2007/03/13(火) 14:08:41
/usr/src/sys/geom/geom_subr.c:g_attach で割り当て
られたデバイス、つまり上の場合 HDD ではないかと想
像するが自信はない。
0088名無しさん＠お腹いっぱい。
2007/03/13(火) 17:13:54
ttp://lists.freebsd.org/pipermail/freebsd-hardware/2004-October/001990.html

ちょっと古い情報だけど。

・きちんとしたハードウェア RAID ならドライブ内の
キャッシュを無効にするし、バッテリバックアップ付き
のキャッシュを持っている（書き込み保証がある）。

・タグつき書き込み対応ドライブなら複数の write 要
求を同時にこなせて、それぞれのステータスを取得でき
る。

・一台こっきりのディスクなら hw.ata.wc=0 にするの
が安全だけど遅すぎるのでデフォルトは 1。

ってところか。

まぁ softupdates が保証するのもファイルシステムの
整合性だけであってユーザデータがどうなろうと知った
こっちゃないわけで、バックアップ取っとけってことで
すな。
0089名無しさん＠お腹いっぱい。
2007/03/14(水) 21:38:12
>>88
>> softupdates が保証するのもファイルシステムの整合性だけ
保証できているかが議論の対象なんですよね？
0090名無しさん＠お腹いっぱい。
2007/03/14(水) 23:33:49
そもそも守りたいのはファイルシステムの整合性じゃなくてユーザーデータ。
ただユーザーデータを守るにはファイルシステムを守らないといけない。
鶏が先か卵が先か。
0091名無しさん＠お腹いっぱい。
2007/03/14(水) 23:47:04
全然にわたま違うやん。
ファイルシステムを守ってもユーザデータを守れるとは限らない。
ユーザーデータを守る方法はほかにいくらでもある。
0093名無しさん＠お腹いっぱい。
2007/03/16(金) 04:35:11
>>89
>>> softupdates が保証するのもファイルシステムの整合性だけ
>保証できているかが議論の対象なんですよね？

多分それもレイヤに分割されて、

1) softupdates の考え方だと保証できる
2) 1 に基づいて正しく設計されてる
3) 2 に基づいて正しく実装されてる

という話なんだろうね。で、1 ですら懐疑的な人がいて
話が進展しなかったり…。

「え？結局バックアップ頼り？じゃあ危ない橋渡ってで
も早い方がいいじゃん」ってのもあるのかな。
0094名無しさん＠お腹いっぱい。
2007/03/16(金) 10:11:27
>>93
ttp://journal.mycom.co.jp/articles/2007/03/13/bluffs/002.html
1でも、今世紀のデバイスでは保証できないことが多い、という状況じゃないかな。
0095名無しさん＠お腹いっぱい。
2007/03/16(金) 10:56:29
リッチな解決：
バッテリバックアップキャッシュなRAIDを組む。
バッテリバックアップキャッシュなドライブを買う。

プアな解決：
WriteCache を無効にする。

？な解決：
安全性よりスピードを優先して WriteCache を有効にし、
バックアップ頻度を上げる。

…っていう運用の話になるのかね？
0096名無しさん＠お腹いっぱい。
2007/03/16(金) 12:21:52
>プアな解決
実際問題として、これで運用できるのかな。
管理してるだけで自分は使ってないよっていうのはなしで。
0100名無しさん＠お腹いっぱい。
2007/03/19(月) 11:03:39
>>98
ttp://en.wikipedia.org/wiki/Tagged_Command_Queuing

この最後に completion message がどうの、とあるんで
それ使えるんじゃないかな。

「高速化のためにディスク内で書き出し実行を入れ替え
てもそれぞれの終りが検出できれば良い（安全なものだ
け並列実行する）」というのは、ちょっと考えれば「ディ
スク内キャッシュを使わなくてもホスト側で充分に大き
な外向きバッファがある」のと結局同じ話になると思う
（softupdates はバッファ内で安全な入れ替えや統合を
行うから）。

ところが上のレポートにもあったように実際はかなり遅
くなる。すぐに思いつくのは

１）想定している「連続領域」が実際は連続していない
（ディスク側とディスク構造やエレベータに関する認識
が違う）。

２）外向きバッファが充分に効率よく稼動していない
（I/O の書き出しキューに入ってしまうと統合／入れ替
え対象外になってしまう）。

って辺りかな（外してるかもだ）。

書き出しに使ったバッファはそのまま読み出しキャッシュ
として再利用してるので、非常に遅くなるのは何か致命
的な部分がある気がする。これも SMPng みたいに特定
の状況下でチューンすべきかもね。
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況