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/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 のわい、高みの見物
2019/08/21(水) 00:44:36.61
>>816
ちょっと君降りてきなさい。
俺を見下してんじゃねえぞ！！
818名無しさん＠お腹いっぱい。
垢版 |
2019/08/21(水) 03:22:27.79
rm -Rf /
2019/08/21(水) 13:04:05.50
>>817
ボクは涙を流しながらキミの屍を踏み越えてゆくよ (;o;)/~
2019/08/21(水) 17:20:52.80
>>819
君の姿は、僕に似ている
2019/08/21(水) 17:32:34.39
>>819
そして僕にも似ているよ…ｳﾌﾌ
2019/08/23(金) 07:03:11.32
おまえらやっぱ学校や職場で異常なヤツって思われてる?
2019/08/23(金) 07:08:37.01
>>822
そんな君も場末のスレの観察とかしてるあたり普通ではないと思うぜ
2019/08/23(金) 07:21:22.59
BSDの管理なんて知ってたって、おかしな人扱いだよね。

15年前は馬鹿にして見下してたlinuxの方が必要性があったりする。


まだ自分らが賢いと思ってるの?
825名無しさん＠お腹いっぱい。
垢版 |
2019/08/23(金) 07:41:24.93
>>824
そもそも本当に賢い出来る人が寂れた5chの寂れた板に残ってるとは思えない
2019/08/23(金) 07:53:04.25
じゃあ賢いふり止めような
2019/08/23(金) 08:16:56.85
>>824
>>826
わかってないなあ。それが出来ない輩が住み着いて俺様気取ってるわけで、どこでも似たようなもんだろ？
あと、人に説教するときは自分の行動も顧みよう。
問題は解決したんだろうから粘着するのは大人気なくない？
https://mevius.5ch.net/test/read.cgi/unix/1012808941/940-943
2019/08/23(金) 08:39:55.50
>>827
それ、943と940は同一人物だろ。

どういう反応するか見てたんだろ
2019/08/23(金) 08:42:46.46
問題が、おまえらみたいなキモいユーザがこうして徒党を組んでいることにあるとするなら、

こういうスレがつぶれるまで行動するのは、粘着とは違うんじゃない?
2019/08/23(金) 08:43:48.97
BSDを少しでも多くの人に試してもらうには

キモいユーザが大きな足枷になってるんだ。

分かるかい?
2019/08/23(金) 09:19:19.03
何だかんだ言いつつ粘着くんがBSDをこよなく愛していることはひしひしと伝わってきた
ブートローダーの設定もわからないながらBSD(FreeBSD限定)を広めようと邁進しているらしい
ちなみに俺はよくわからない。あまり困ったこと無いから。
ブートで困ったのはUEFIの自動ブートくらいかなあ
2019/08/23(金) 09:23:15.20
>>830
自己紹介乙です！
2019/08/23(金) 12:06:35.04
MacOS X使い＝BSD使いやろ
2019/08/23(金) 12:17:41.56
>>830
BSDを少しでも多くの人に試してもらうには、
Ubuntuや他のLinuxのように、インストーラをGUIにして、インストールが終わったらすぐGUIで使い始められるようにするだけでいいはず。
2019/08/23(金) 13:06:47.80
よろしい。

肩入れするのは止めだ。
2019/08/23(金) 15:00:34.33
>>834
つProject Trident
2019/08/23(金) 16:02:33.76
>>834
Mac使え
2019/08/23(金) 17:59:44.83
macOSってインストーラーなんて配布してた？
条件反射的にmacOS，macOSって言うのやめたほうがいいよ
2019/08/23(金) 18:06:37.38
>>834
では>>830に実装してもらおうぜ
840名無しさん＠お腹いっぱい。
垢版 |
2019/08/23(金) 21:07:34.87
よし、じゃあ賢くないふりをしよう

からあげウマウマ
2019/08/23(金) 21:57:54.38
BSDをぶっ壊す!!、とか言えばいいんじゃ。
2019/08/23(金) 22:17:34.42
ポエマー発見
パクリで草
https://mevius.5ch.net/test/read.cgi/unix/1091212801/811
843名無しさん＠お腹いっぱい。
垢版 |
2019/08/23(金) 23:49:05.35
>>840
レモン汁かけときますね！！！
2019/08/23(金) 23:51:09.56
>>843
勝手にレモン掛けるな！
全員がレモン掛けて欲しいわけじゃないぞ！
2019/08/24(土) 01:28:12.12
じゃあママレモンかけますわね
2019/08/24(土) 07:57:56.91
昔オカンがママレモンで野菜洗ってたのを思い出す
2019/08/24(土) 10:52:56.29
>>836
TrueOSの後継ですね。TrueOSは重くて嫌いだったので使いませんでした。
Project Tridentのほうはまだ日本語対応していないので、手動で入れないといけないみたいです。
https://qiita.com/EarthSimilarityIndex/items/6089500d1a4d24731ee8

誰か日本語対応にしたディストリを提供すればもう少し普及するかも。
2019/08/24(土) 11:12:01.41
ママレモン

【品名】
台所用合成洗剤

【用途】
野菜・果物・食器・調理用具用
2019/08/24(土) 11:57:11.83
野菜・果物の方が優先度高いの草
2019/08/24(土) 12:12:31.90
ナマレモン
2019/08/24(土) 13:04:11.22
>>847
TrueOSって中身はほぼFreeBSDだし、重いというのがluminaのことならどのWM使っても重いんじゃ？
2019/08/24(土) 14:19:54.49
よーしパパ、今度休みが取れたら軽量なWM作っちゃうぞ―
2019/08/24(土) 14:35:11.10
久し振りに5chに神が降臨されました
2019/08/24(土) 14:45:32.49
車輪の再発明は止めるんだ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況