たけふ@大阪豊中です
丸山直昌 wrote on 2016/01/05 22:53:
> 知りたいのは zfs のファイルシステムをどのように運用されていらっしゃるの
> かです。元々のメールにある dmesg に出ている /dev/ada0p2 は、普段の運用で
> は使っていないトラブルシューティング用の予備 root なのでしょうか、それと
> も普段も root として使っていて、件の zfs ファイルシステムはその下にマウ
> ントする運用をされているのでしょうか。
今回の事例では、ufs で構築していた HDD が容量不足となり、
それに伴い、HDD を丸ごと別の大きい容量の
たけふ@大阪豊中 様
統計数理研究所の丸山です。
やはり私の知識ではお役には立たなかったようですね。問題は解決したようです
ので、大変恐縮ですが、私の向学のために少し質問させてください。
知りたいのは zfs のファイルシステムをどのように運用されていらっしゃるの
かです。元々のメールにある dmesg に出ている /dev/ada0p2 は、普段の運用で
は使っていないトラブルシューティング用の予備 root なのでしょうか、それと
も普段も root として使っていて、件の zfs ファイルシステムはその下にマウ
ントする運用をされているのでしょうか。
一連のメールで示された解決
たけふ@大阪豊中です
Akihiro HIRANO wrote on 2016/01/05 15:36:
> zfsはメモリ喰いだそうで、カーネルメモリ空間を食い尽くすと、
> カーネルがパニックして落ちるそうです。
そのようですね。
VMware Player の利用できるメモリを 3.5G にまで広げてみたのですが、
相変わらずの状況でした。
> 物理メモリが2GBであれば、vm.kmem_sizeやvm.kmem_size_maxを
> 3GBにしてみると良いかもしれません。
これは試したトコ、カーネル自身が上がらなくなってしまい、
結局、vm.kmem_size 及び vm
たけふ@大阪豊中です
Hajimu UMEMOTO wrote on 2016/01/05 16:27:
> ume> options KVA_PAGES=512
>
> options KSTACK_PAGES=4
>
> ume> が必要になってます。
> ume> /usr/src/UPDATING の 20121223 のエントリを参照。
>
> ume> また、i386 だと
>
> ume> options KVA_PAGES=512
>
> ume> が必要だと思いますが、その辺もご注意を。
>
> ume> https://wi
たけふ@大阪豊中です
丸山直昌 wrote on 2016/01/05 15:28:
> これは zfs の問題ではないと思いますが、取り合えず
>
> fsck_ufs /dev/ada0p2
> mount -u /
>
> をやってから
>
> zfs list
> zpool list
>
> などをやっては如何でしょうか。
メールには、書いていませんでしたが、
ufs の不整合では zfs のコアダンプは解消されませんでした。
___
freebsd-users-jp@fre
たけふ@大阪豊中です
Kouji Kawabata wrote on 2016/01/05 16:54:
> zfsでコアダンプしたりパニックするのは
> 大抵メモリ不足だと思います。
結果、そういう事でした。
> 私もi386でのzfsはかなり苦労しました・・・というかamd64にすべきです。
> 実験とのことですが、i386では早晩メモリが足りなくなります。
そうですね。
amd64 で構築しなおす事も検討しておきます。
> どうしてもi386でと言うことでしたら
> i386でPAEカーネルを作ってzfsしてる人も居たと思いますので
> ぐぐってみてください。
メモリ不足のヒン
川端@JIPPGです。
zfsでコアダンプしたりパニックするのは
大抵メモリ不足だと思います。
At 16:18 16/01/05, you wrote:
>paseri> zfs の実験をしていて、障害発生時の対応を調べているのですが、
>paseri> 何処から手を付けていいやらで、zfs お使いの皆さんから、
>paseri> ノウハウをお聞きしたく思います。
>
>paseri> 症状:
>paseri> VMware Player の環境下で、10.2-RELEASE-p7(i386) 上で、
>paseri> ホスト OS の再起動によって、umount せずに電源 OFF