FreeBSDを語れ Part47

■ このスレッドは過去ログ倉庫に格納されています
2017/10/16(月) 01:40:28.46
The FreeBSD Project
http://www.freebsd.org/ja/

前スレ
FreeBSDを語れ Part46 [無断転載禁止]@;2ch.net
http://mevius.2ch.net/test/read.cgi/unix/1505956006/

関連スレ
初心者もOK! FreeBSD質問スレッド その122
http://mevius.2ch.net/test/read.cgi/unix/1486758875/
2019/08/02(金) 01:13:12.31
>>716
これってもしかしてラマヌジャンの公式？
2019/08/02(金) 10:08:53.16
モンテカルロ法でやるんや
2019/08/02(金) 10:38:37.47
サイコロ何回振れば良いんだ？
2019/08/05(月) 22:28:52.61
FreeBSD＋Firefox→ニコニコ動画で広告が再生される
Windows＋Firefox→ニコニコ動画で広告が再生されない
なんじゃこりゃ。どちらも未ログインかつADブロッカー的なのは入れていない
2019/08/05(月) 23:38:16.34
別に大丈夫だけどな
出るときは出る、出ないときは出ない
https://i.imgur.com/XCKb6wF.png
2019/08/06(火) 13:29:09.83
portsにllvm90が降ってきた
rcだけど
2019/08/06(火) 13:36:59.48
そんなことより、libpciaccessのエンバグ何とかしてくれ
アプデしたらxf86-video-vesaが死ぬとか…
2019/08/06(火) 13:54:37.51
ワイnon vesaでオンボのボロノートだからよくわかんないや
725名無しさん＠お腹いっぱい。
垢版 |
2019/08/06(火) 14:58:46.31
ffはたまに知らんうちにnicoをブラックリストに入れるときがある
ブラックリストに入ってないか確認してみ
2019/08/06(火) 18:59:14.82
vesaのバグ(先月くらいから？)にははまったな。
サボらずにビデオカードのドライバにかえたよ
2019/08/06(火) 20:20:27.06
Bug 239065
devel/libpciaccess 0.14 breaks x11-drivers/xf86-video-vesa-2.4.0_2

libpciaccess 0.16のFixあったけど
まだ落ちてこない
まぁ、落ちてくるまで0.13.5にダウングレードして待ってる
2019/08/06(火) 22:20:58.86
libpciaccess、依存パッケージを含めてもビルドに1分かからないよ
729720
垢版 |
2019/08/07(水) 00:47:27.60
昨夜は動画を再生するたびに広告が再生されて鬱陶しいったらありゃしなかったけど
今夜は一度も再生されないな。なんなんだろ
2019/08/07(水) 02:55:28.53
慌てない　慌てない
一休み　一休み
2019/08/07(水) 03:01:39.07
そして10年後・・・
2019/08/07(水) 04:20:55.37
一体何が始まるんです？
2019/08/07(水) 06:26:53.50
CM開け一休さん
2019/08/09(金) 16:55:35.38
日本船舶振興会がスポンサーなのに彼女はサヨちゃんて。
2019/08/09(金) 17:14:24.74
一日一善！
2019/08/09(金) 17:17:10.99
のほほほほ
2019/08/09(金) 21:02:49.10
>>734
修行僧なのに女を作るような奴はサヨだってことだろう
2019/08/09(金) 21:19:08.71
>>734
その発想はなかった
2019/08/10(土) 05:58:17.88
いわゆるファイアーウォール、1つあれば十分じゃね?
2019/08/10(土) 07:48:49.14
貴方はどのファイアーウォール？
ワタシはipfw
2019/08/10(土) 08:41:43.75
わたしはpfから
2019/08/10(土) 08:54:15.87
natするのはipでやってて手打ちするときはipfw 使うかな。
743名無しさん＠お腹いっぱい。
垢版 |
2019/08/10(土) 08:54:42.26
ipじゃなくてipf
2019/08/10(土) 09:27:11.20
srcからipfwとpfを削除するスクリプトを誰か書いてくれよ
745名無しさん＠お腹いっぱい。
垢版 |
2019/08/10(土) 09:47:42.16
ファイアウォールは使ってない
ルータ任せ
2019/08/10(土) 20:26:54.94
ゲートウェイマシンをFreeBSDで動かしてるとどうなるか
2019/08/10(土) 21:06:40.94
あっさり踏み台にされるとか
748名無しさん＠お腹いっぱい。
垢版 |
2019/08/10(土) 23:14:24.34
一通りの対策はする必要があるね。
外側のネットワークからは入れないようにするとか。
そうしておけばそこまでの問題にはならない。
2019/08/10(土) 23:35:30.49
OpenVPNでトンネリングしたいけど、IP限定&AES-256-GCM&ta.keyで大丈夫かな
トンネル要因のラズパイのOSをRaspbianからFreeBSDに乗り換えたくてウズウズしてるもので
2019/08/11(日) 05:12:20.73
>>744
なんで？
2019/08/11(日) 05:36:42.32
>>750
PCのOSに関しちゃ要らないものを削除した方がいいと信じてるから
752名無しさん＠お腹いっぱい。
垢版 |
2019/08/11(日) 07:06:36.30
まあ何もしなくても、機能を有効にしなければモジュールもロードされないわけだから、
ちょっとだけディスクを使うだけなんだけどね。
2019/08/11(日) 07:18:53.00
device pf と options IPFIREWALL 外してカーネル再構築してもナンカ混じってるのけ？

BSDだけじゃなくってlinuxにも言える事だけど、10年以上前、
外しまくったらそれはそれでたまーに動かないモンがあったりしてハマった記憶があるな
外しまくればいいってもんでもない
2019/08/11(日) 07:22:08.49
本来開発段階で削除すべき

選択肢はportsで十分
2019/08/11(日) 08:32:06.16
fetchindex が途中でコケなくなった(ような気がする)
2019/08/11(日) 13:34:55.56
さて、メタボ化した/usr/localの断捨離でもするかの
rm -rf /usr/local/* っと
757名無しさん＠お腹いっぱい。
垢版 |
2019/08/11(日) 13:40:46.75
元気ですね。
2019/08/11(日) 14:23:04.77
ダンシャリとか簡単に情報に踊らされるタイプなw
2019/08/11(日) 14:44:44.70
ちっさｗ
2019/08/11(日) 17:21:13.91
ダンミツがどうしたって？
761名無しさん＠お腹いっぱい。
垢版 |
2019/08/11(日) 17:24:34.73
ときめくファイルかときめかないファイルか
( spark joy or not)
2019/08/11(日) 17:39:11.39
FreeBSDを使うやつっておかしい奴が多いの?
763名無しさん＠お腹いっぱい。
垢版 |
2019/08/11(日) 18:02:18.47
えっ？
2019/08/11(日) 20:38:37.15
アンミツは甘い。(真実)
2019/08/14(水) 15:13:25.68
さてさてZFSのデフラグを兼ねてニューSSDに引っ越しだ
わくわく
2019/08/16(金) 14:10:25.57
デフラグメンテーションなど幻想
2019/08/16(金) 15:12:10.48
幻想である根拠はハードウェアに詳しくないのでよくわかんないけど、実際同じ様なスペックでブート等早くなったし、ひとつのファイルをバラバラの場所から読み取るより物理的に疲弊しないのでは？
まあ主目的は引っ越しなのでそんなちっせえ事どうでもいいけどｗ
2019/08/16(金) 20:09:39.52
Unix/BSD系のファイルシステムは最初からデフラグメンテーションが起きにくいようになっているので、
デフラグツールがあったとしても頻繁に実行する必要はない。普通はしなくても問題ない。
Windowsのファイルシステムは基本的に貧弱なので、デフラグを実行すると少し早くなる。
何ヶ月もデフラグしていないときにやると効果が大きい。
2019/08/16(金) 20:38:56.07
いやあ、しばらく使った内蔵SSDが120GBでは足りなくなってきたので240GBに引っ越しただけの話なのですよ。
zpool get fragmentationしたら40%に近かったので「デフラグを兼ねて」と付け足しただけで。
2019/08/17(土) 08:33:25.66
current追っかけをやってたときは、年に1度くらい / と/usr をnewfsして書き直してたけどな。　

気分の問題だよ
2019/08/17(土) 10:32:25.73
つうかSSDの書き込み回数はQLCに至っては300〜1000回しかないから、同じ所に書き込まないように複雑なアルゴリズムで思いっきり分散されてるだろ
2019/08/17(土) 11:47:21.90
SSDにシーク時間や回転待ち時間はないだろ
デフラグなんて「気持ち」以外に意味ない
HDDだって巨大なデータの高速シーケンシャル処理でもない限りさほど恩恵はない
NetwareのTurboFATみたいなアクセスオーダー最適化機構の方が意味あると思う
2019/08/17(土) 13:34:05.98
HDD時代はシークや回転待ちの方が桁が大きかったゆえに顕著だったから勘違いされてるが
フラグメンテーションによる速度低下の本質は細分化されたブロックを操作するためにコマンド数が爆発する方なんやぞ
だからSSDでもPCI ExpressでもRAMディスクでも小ブロック操作は相対的に遅くなる
2019/08/17(土) 13:50:45.10
コマンド数が爆発って言ったって
数回が数十回になる程度で速度に影響はないよ。
それよりも読み込み時間のほうが圧倒的に長くなる
2019/08/17(土) 15:01:25.57
まあどんなファイルシステムでも程度は違えど断片化するし、そうなればパフォーマンスが落ちる事は改めて学習した。古いこの記事読む限り
https://www.itworld.com/article/2812382/unix-tip--fragmentation-and-unix-file-systems.html
2019/08/17(土) 15:22:56.99
断片化をいつ解消するかだよな。
あるOSは書き込むたびに断片化を解消させるために余計なアクセスを行ってるらしい
そんなことをするより、定期的にバックグランドで負荷をかけないように
程度のひどい部分だけ解消させたほうが良かろう
2019/08/17(土) 16:37:29.49
ZFSはプール作り直さないとならないからなあ
2019/08/17(土) 19:01:14.25
だからSSDはセクタ単位で書き込み回数が均一化するように分断されまくってんじゃないのか？
2019/08/17(土) 20:18:04.51
zpool作り直せばええ
簡単やろ
2019/08/17(土) 20:46:02.67
確かにプール作り直してrsyncとかスナップショットrecvで書き戻せば元通りだけど、未だにそれしか断片化解消出来ないのもなんだかなあと思う
他の部分が便利すぎるからまあいいか
2019/08/17(土) 21:25:02.07
ちなみにZFSはHDDでもよく断片化する。make worldしたり頻繁にports使ったりすると割とすぐ20%くらい断片化する。
機会があったらUFSに戻して違いを検証してみるか
2019/08/17(土) 22:10:25.36
>>778
されてない。そもそも断片化と書き込み回数の均一化と何も関係ない。
OSのイメージなんてそうそう書き換わらない。
それじゃいかんからSSD側が頑張ってる。
2019/08/18(日) 00:01:06.97
断片化するといっても、リニアにギガオーダーのファイルをリアルタイムに読み込むことも稀に思う。
スワップをメモリファイルやZFS以外ににマウントすれば、そうそう困らないと思う。
データベースファイルとか頻繁に更新したり、レスポンスを要求されるならば、それをZFSに配置するのが設計不備に思う。

このあたりはZFSのマニュアルにも書いてあったと思う。
2019/08/18(日) 00:01:56.91
>>782
言ってることが物凄くアバウトだな…
785名無しさん＠お腹いっぱい。
垢版 |
2019/08/18(日) 00:15:15.86
>>773
なんか脆弱性の種を見つけた気がした。
コマンド数を減らしたい！
→そうだ別セクタも無差別にメモリ転送して、プロセッサで取捨選別した方が合理的じゃね？
→いいね！ 実装
→ HTスペクターで読み込もうっと！
→あれ？他人のファイルの中身の一部がよめたぉ！
とか
2019/08/18(日) 01:18:19.48
>>784
1. DVDのISOイメージを保存しました。
2. このイメージを書き換えることはしません。
3. ずっと保存してると、このISOイメージの場所は書き換え回数が少なくなります。
4. SSDの書き込み回数の均一化というのは、こういう書き換わらない場所すらも均一化するものです。

理解できた？
787名無しさん＠お腹いっぱい。
垢版 |
2019/08/18(日) 02:47:13.58
>>786
論理セクタは断片化されぬとも物理セクタは断片化されることを>>778は云っておろう？
それともうぬは物理セクタすら断片化されぬと云うつもりか？
2019/08/18(日) 02:47:56.21
>>787
いまはSSDの書き込み回数の均一化の話をしてますー
2019/08/18(日) 05:58:14.52
>>783
じゃあOSやアプリケーションのアップデートをまめにやりたい人はFreeBSDのインストール時にUFSを選択せよと言う事だな。スワップパーティションはわざわざ無しにしなけりゃ自動的に作られるし。
どうやらファイルシステムにお詳しい様なので聞きたいんだけど、何故ZFSはあまり書き換えてはならない？
となると、スナップショットは何の為にあるわけ？
巨大ファイルにアクセスしなくとも、断片化が30%くらいに進行すると体感出来るくらいはパフォーマンスの低下を感じる事が出来るけど？
あとUFSとZFS、どっちが断片化しづらい？そしてその根拠をご説明頂きたい。
教えて下さいよ大先生
2019/08/18(日) 07:50:32.73
断片化が30%になるってどういう情況だろうか？

インストールやファイルコピーでは断片化はほとんどしないから、
全体の使用量の30%以上を更新してるはず。

いや？そもそも断片化30%ってどういう計算なんだろう。
1GBのファイルが有って、それが2個に分かれていたら1GB分、断片化？
いや違うな。ファイルの個数に対する割合だろう。
この場合、1個のファイルが1回断片化ってことだな。

ってことは、全体のファイル数の30%の数だけ書き換えているということか。
うーん、でもその場合、1GBのファイルが100個あったとして、
30個のファイルが断片化していたとして、その300GBのデータを読み込んでも
たった30回しか断片化による影響を受けないはずなんだよな。

本当に30%で体感できるパフォーマンス低下が起きるんだろうか？
2019/08/18(日) 08:14:59.95
>>786
SSDは、ISOイメージのように一度書き込んで動かさないファイルであっても、その位置の書き換え回数が少ないと判断したら
勝手に他の位置に移動して場所を空け、そこに他のファイルを書き込むということ？
2019/08/18(日) 09:20:48.81
>>790
質問の答えになってないよ大先生
あと、持論ばかりじゃなくログ読みなよ、make worldしたりports頻繁に使ったらって書いてあるだろ
それとまさか断片化を確認するコマンドくらいはわかるよなあ大先生？
2019/08/18(日) 09:27:29.81
実はファイル作成では断片化することはほぼ無い。削除も当然。
ファイルを作成するときに、どうしても連続する領域を確保できなかったときと、
ファイルサイズを増やしたとき。

あるプログラムがファイルの作成と削除を何回も繰り返したとしても
断片化が著しく増えることはない。
2019/08/18(日) 13:06:35.01
>>792
横槍すいません。
断片化を確認するコマンドってなんですか。
2019/08/18(日) 13:07:56.00
なるほど、当たり前の様でも案外忘れがちな事ですな。変に詳しくなればなるほど。
今晩あたりいろいろ実験してみるか。俺も割とUnixのFSを過信してた方なので
796名無しさん＠お腹いっぱい。
垢版 |
2019/08/18(日) 13:33:12.85
>>794
zpool list 又は zpool get fragmentation
こちらの大先生は大層ファイルシステムに、特にZFSにお詳しいご様子だったのでこの位はご存知かと思いご質問させて頂いたのですよ
そうでもなければ安易に「設計不備」とかほざくわけがありませんからな
まあ実際このコマンドでファイルの配置が目視できるわけじゃございませんけどね
2019/08/18(日) 16:01:40.64
今時フラグメンテーションを気にする男の人って…
2019/08/18(日) 16:47:13.28
ちっさいよねぇｗ
調子悪くなったら取り替えればいいのにねー　か。
でももったいないしね。色々と
2019/08/18(日) 17:37:17.34
>>792
Windowsしか理解出来ないパソコン先生に無茶言うなよ
2019/08/18(日) 18:03:53.65
>>799
それもそうだね
ぼく大人気なかったね。アハハ
2019/08/18(日) 19:37:30.32
SSDの書き換え回数を公表してるメーカーは少ないけど以前Intelが公表した回数はQLCでたった200回だ
こんなん、こまめにセーブしてたらあっという間に越える
だから物理的にはバラバラに断片化されてるに決まってる
だからSSDではデフラグは無意味だろうし余計なことしない方が良いだろう
2019/08/19(月) 00:48:52.27
そこらへんWindowsではちゃんと考えられていて
ディスクがSSDだったらデフラグしないようになってる。
代わりにtrimを行う。

FreeBSDがそこまで気を配ってるかどうかはしらん。
2019/08/19(月) 00:51:57.29
なお、デフラグするたびにディスクに書き込んでると思ってるやつがいるが、
前回デフラグしてから、仮になにも書きこまれてないならば、
すでにデフラグ済みなので、デフラグを実行しても何も書き込まれない。
2019/08/19(月) 01:48:46.00
FreeBSDでもtrimを有効にする事は出来る様だ
但しUFS限定
2019/08/19(月) 01:56:21.91
失礼、ZFSでも可能な模様
2019/08/19(月) 02:15:26.92
結局Unixファイルシステムにおいても断片化はするし、放置したら宜しくないからその対策もされてるわけだ
言い伝えなんて出鱈目だよな
2019/08/19(月) 09:00:31.07
おまえらBSDユーザみたいな議論してるのな()
2019/08/19(月) 14:19:33.27
>>802
Windowsではオートデフラグのタスクが走っていて定期的にデフラグするようになっているが、
これを切っておけは勝手にデフラグしなくなる。昔のWindowsみたいに、自分の好きなデフラグソフトDLして、
自分がデフラグしたいときだけ実行することができる。
2019/08/19(月) 14:41:23.14
なおFreeBSDのUFSではtunefs -t enable /dev/hogeでtrimを有効化出来る
ZFSでは割と前からデフォルトでtrimが有効化されている。trimを止めたい人以外は意識する必用は無い
2019/08/20(火) 06:52:12.83
いつまでLD=ld.lldしなきゃならないの

12.1が2019.11.4にリリース予定だけど、移行は終わる?
2019/08/20(火) 16:28:59.82
>>810
https://i.imgur.com/yYYOUaZ.png
特に何もしていない
2019/08/20(火) 17:25:30.63
はぐらかして自分は賢いつもりのBSDユーザー
2019/08/20(火) 17:41:08.19
あーやだやだ
2019/08/20(火) 18:08:58.94
812は>>811が何を言っているのか読み取れないの？
大人の人ってすごいねって言うだけのおこちゃま？
なんにせよ :fu: 812
2019/08/20(火) 18:20:33.22
画像は消えてるけどls -l /usr/bin/ld* してみなよって感じだった
2019/08/20(火) 18:33:10.12
11.3-STABLE のわい、高みの見物
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況