[過去ログ] 初心者もOK! FreeBSD質問スレッド その124 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
480
(1): 2020/08/10(月)17:22 AAS
>>475
CFT for FreeBSD + ZoL
外部リンク[html]:lists.freebsd.org

上の記事を見たんだけどZoLっていうのを試せばzpool removeが動く可能性あり?
ちなみにこの記事のリンク先の
外部リンク:pkg.trueos.org
がTrueOS ディスコンに伴い無くなってる。
481
(1): 2020/08/10(月)18:19 AAS
>>480
出来ちゃった
sysutils/openzfs を使えばいける

>>476
てなわけで memstick.img から sysutils/openzfs 入りのカスタムライブUSB作ってチャレンジするのがお勧め
482: 2020/08/10(月)18:58 AAS
平面362度
483
(1): 2020/08/11(火)06:12 AAS
>>481
いけたんだね。有益な情報ありがとう。
こちらは12-RELEASEから12-STABLEにしてpkgでopenzfsとopenzfs-kmod入れて
/boot/loader.conを
#zfs_load="YES"
openzfs_load="YES"
にして起動。
すると
/usr/local/sbin/zpool (openzfsのツールが置かれるパス)
でzroot以外つまり自分で作ったtankなどが見えなくなった。なぜzrootだけ見えるのか
は不明。

/boot/loader.conを戻して既存のzfs.kmodを使えばzroot以外も無事現れたんで一安心
なんだけど,ちょっと落ち着いて作戦を立て直します。
484
(2): 2020/08/11(火)06:54 AAS
>>483
こちらも12.1-STABLE
以下やった事や現象

・/boot/loader.confの記述
 zfs_load="YES" # つまりデフォルトのまま
 zfs_name="/boot/modules/openzfs.ko"
・/etc/rc.confは特に弄らず
・ブート時zroot以外は自動importされないものの、手動でimportする事は可能
・openzfs.koがロードされている状態であれば
 ストライピングしたストレージの切り離しが
 /usr/local/sbin/zpool remove プール名 ストレージ で可能

但しルートプールしか自動importされないと言う解せない現象もある為
仮想環境やサブマシン等で十分に検証される事を推奨致します
485
(1): 2020/08/12(水)18:03 AAS
>>484
removeできるvdevの条件について教えてください。例えばHDD3台でraidz1構成のプール
があったとして,ここに1台をストライピングで足して
# zpool add tank ada6
# zpool status tank
tank ONLINE
raidz1-0 ONLINE
ada1 ONLINE
ada2 ONLINE
ada3 ONLINE
ada6 ONLINE

ここで
# zpool remove tank ada6
cannot remove ada6: invalid config; all top-level vdevs must have the same sector size and not be raidz.
と言われる。raidzの構成に入ってないディスクのremoveなのにだめなのか?
ada6とraidz1-0はストライピングなのに。

ここでも似た質問してる。
外部リンク:serverfault.com
486
(1): 2020/08/12(水)18:05 AA×

487
(1): 484 2020/08/12(水)18:56 AAS
>>486
自分が成功した時のプール構成(単純ストライピング)

ada1p1(元々のパテ /dev/gpt/hoge1が識別子)
ada2p1(先月ストライピング /dev/gpt/hoge2が識別子)
da0(USBメモリ 昨日ストライピング)
da1(同上)

このうちda0、da1のremoveに成功 ada2p1は使用中につきそのまま

夕飯後に(仮想HDDイメージですが)同様の構成で検証してみるのでしばしお待ちを
実機でも再現出来るかは保証出来ませんが
488
(1): 2020/08/12(水)19:05 AAS
>>485
横からだけど
tankを構成するトップレベル【全ての】vdevsにraidzがあったらダメってエラーじゃないの?
489
(1): 2020/08/12(水)19:27 AAS
>>487
お手数かけ,痛み入ります。

>>488
文字通り読めばそうですね。ただストライピングのremoveの処理が
実現できているのに上の例のremoveができない理由が想像つかないので
できるとばかり思ってました。
490
(1): 2020/08/12(水)23:56 AAS
>>489
検証結果
結論から言うと488さんの仰る通りですね。

・raidzにストレージを1つストライピング
→同様のエラー発生
 そもそもストライピングする時点で「invalid vdev specification」「use '-f' to override the following errors」とエラー出力
・raidzにraidzをストライピング
→同じくエラー

尚RAID0相当の単純なストライピングでもashiftの値が揃っていなければremove出来ません
491: 2020/08/14(金)05:39 AAS
>>490
ありがとうございます。
そうか,zpool removeは現状ではちょっと期待外れだったけど今後の機能拡大に
期待します。
492: 2020/08/22(土)11:33 AAS
OI148からsend&recvでFreeBSD12.1にzvolを転送したら
ボリュームサイズ350GBがリファレンス500GBオーバーに化けたんだけど何が起きたかわかる人いますか?

どちらもディスク5台でraidz2の構成、スナップショットはsendの為に作った物だけ。圧縮も重複排除も無し。
OI側ではvolsize、referenced、volsize、usedbydatasetはほぼ一致。
心当たりと言えばOIは512BセクタでFreeBSDは4kセクタくらい?
493: 2020/08/22(土)12:33 AAS
そもそもsend/recvの互換性は保証されていないんじゃ
494: 2020/08/22(土)12:47 AAS
コードベースは同じ筈なので建前的には互換性があると思います。
とくにOI側が古いので問題は起きないと思いました。
プールをリリースバージョンそのままで作っているので逆方向は問題を起こすとは思いますが
ストリームはバージョンチェックが入っているはずなのでそこで止まる筈…。
495: 2020/08/22(土)14:52 AAS
truncateで作ったファイルがあったとか?
496: 2020/08/22(土)15:26 AAS
シンプロビジョニングとかでボリュームサイズより200GB近くも大きくなるのは無いかなと。

ちょっと検証してたんだけどvolblocksizeが小さい時に出るパリティオーバーヘッド分がデータセットの占有サイズに入っているっぽい?
64kで検証中だけど150G書き込んで170G占有だから予測的には350GB書き込めば397GBくらい。
なんとなく納得できる範囲だけどOIで全くそんなことが無かったのは512Bだからかな。

ワンブロック毎にワンセクタ喰うとしたら単純計算で八倍。それはデカい。
497
(2): 2020/08/27(木)14:29 AAS
freenasのシャットダウンの最後に写真のようなエラーメッセージ?が出ます。
画像リンク


raid6 zfsの環境で、zpool statusとgpart statusにエラーはありません。

何なのか教えて頂ければ助かります。
498: 2020/08/27(木)16:44 AAS
ミラーされた論理デバイス(/dev/mirror/gm0)が、シャットダウンに伴い無くなったよ、てことじゃないの?
再び起動すると、gm0が作成されると思うんだけど
外部リンク:ja.wikipedia.org
499: 2020/08/27(木)19:31 AAS
スワップパーティションが暗号化されてるんだな
暗号化されてるデバイスが起動時に復号されてその後でマウントなりスワップ開始なりされる
シャットダウン時には逆にアンマウントされてスワップが切り離されて復号が解除される
暗号用のキーを格納済みなら全自動だろう
500: 2020/08/27(木)20:32 AAS
>>497
たとえば /etc/fstab に
/dev/ada9p9.eli none swap sw 0 0
のようにスワップデバイスとして指定する時に、存在しないGELIブロックデバイスを指定すると自動で処理してくれる
man 5 fstab の中で eli を文字列検索するといくらか詳しく書かれてるよ
外部リンク[cgi]:www.koganemaru.co.jp

画像はGELIデバイスとGMIRRORを問題なく破棄したっていう報告だから気にする必要はないね
501: 2020/08/28(金)00:30 AAS
sambaでadにjoin出来ない理由で昨日一日頭いっぱいだったんだがリリースノートくらい読めで終わってしまった。

4.10から4.11でプロトコルバージョンのデフォルト値が変わっただけだった。
それでクライアントプロトコルが通じなくなって…エラーメッセージは適切にしてくれと切実に思う。

でもkrb5.confとads用のsmb4.confを思いきりスリム化できたからこれも良し。
502: 497 2020/08/28(金)06:53 AAS
アドバイス有難うございます。規制で書き込めず返信が遅れました。申し訳無い。
503: 2020/09/04(金)01:02 AAS
1. 11.4-p3 が出たので諸々アップデートした(元は11.4-p2)
2. ports にて nginx 1.18.0_24,2 にアップデートされていたので同じくアップデートした
3. nginx -t にて “modsecurity” が認識できないと怒られた。はて?nginx -V してもコンパイルされているもよう

結果:
modsecurity3 を pkg で入れたのを嫌がるようになったみたい?
pkg remove modsecurity3 してから ports にて modsecurity3 をコンパイルすることで何とか起動できた。が、
modsecurity3 は dynamic module に取って代わるようになったようでしたので以下を nginx.conf に追記した
load_module /usr/local/libexec/nginx/ngx_http_modsecurity_module.so;
504: 2020/09/07(月)12:47 AAS
fcitx-mozcなんだけど、libreofficeの特にwriterだと、変換入力から取りこぼしが発生しない?

例えば「だえもん」とローマ字入力しようとして、oが取りこぼされて変換文字列より先にwiterに入力され、
「oだえmん」になっちゃう的なことが高頻度で発生する
calcだと稀にある

ゆっくり入力すれば発生しない
thunderbirdで入力するのは全く問題ない(多分)
505
(1): 2020/09/07(月)19:02 AAS
KDE上でfcitx-mozcを使ってるけど高頻度な取りこぼしはないなあ
だけどアプリケーションは問わずに入力の第一要素を取りこぼすのはたまにあるけど
「kinnpei」と入力すると「いんぺい」てなっちゃう
理由も対応策もわかんないままだけど、本当にたまにしかないから諦めてる
時期的にはここひと月の間からかな?
506
(1): 2020/09/07(月)20:54 AAS
以前は
外部リンク:pkg.freebsd.org
でlatestとかquarterlyとか各リリースごとの全部のパッケージを見れて
バイナリーを落とせましたが今は403 forbiddenでミラーサイトも含めて
見れなくなってます。鯖の負荷が高くなるから禁止したらしいですが。
どこかに代わりのサイトはないでしょうか?
507
(1): 2020/09/07(月)22:18 AAS
>>506
解決方法はわからないけど、とりあえず茶々を入れとく
何を目的としているの?
パッケージを全部ダウンロードしたいだけなら、どうせ無駄になるだけなんだからやめとけって
508: 2020/09/07(月)22:24 AAS
>>505
症状は違うけど、やっぱ取りこぼしはあるんんだね
writerでは高頻度過ぎて、文章入力はthunderbirdでやり、
writerへコピペするという、何やってんだ状態だよw
ちなみにTrueOS+KDEです

atokxやvjeではサスガに取りこぼしなんてなかったな
509
(1): 2020/09/08(火)00:27 AAS
>>507
いかにも思い込みが激しくてコミュニケーション障害を患っているような
頭悪い人の典型な書き込みですね。まあ、実生活では嫌われるタイプでしょう。
知らないなら無理に答えないでいいですよ。
別にあなたのような知識の無い人が答える必要はありませんから。
最新版にして動かないものを元のバージョンのものに置き換えるためですよ。
pkgのconfを書き換えればパッケージを全部ダウンロードしなくても
必要なものだけでpkg install出来るでしょ。
あなたのような人は全部ダウンロードして無駄にするんでしょうけど。w
頓珍漢な返事をしているんだからあなたの今までの人生も無駄だということが
証明されてしまいましたね。ご愁傷さま。
1-
あと 493 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ

ぬこの手 ぬこTOP 0.022s