あきやまじろう
mayam****@gmail*****
2014年 10月 21日 (火) 18:05:16 JST
清水様 あきやまです。 早速の回答ありがとうございます。 > ご認識のように quotacheck は対象のファイルシステムを一旦 real only > でマウントしてスキャン後に read write でマウントしなおすという動き > をします。 > ですので、quotacheck 発行後に発生しているのが特定できているのであれば > -m オプションの付与で回避可能かと思います。 承知しました。 > # noatime は反映されなくなっているのに、nobarrier は有効なまま > # なのはちょっと謎ですが。。。Kernel で設定しています？ カーネルはデフォルトのままなので、barrier が有効になっています。 > ただ、私はディスククォータ関係をあまりいじったことが無いので推測も > 入りますが、マニュアルを確認する限り、スキャン中に対象のファイル > システムに対して書き込むプロセスが無いことを保証できない場合は > 使うべきではないオプションのようですが、この条件をクリアできますか？ > > ちなみに、drbd_quota という RA は自作されたものでしょうか？ > > この RA の内部処理が不明なので何とも言えないのですが、この RA > の処理で quotacheck を動かしているとすれば、いただいた Pacemaker > の設定であれば、上記指摘の"スキャン中に対象のファイルシステムに > 対して書き込むプロセスが無いこと"を保証できるかと思いますので > 上記指摘は無視していただいて結構です。 ご指摘の通りRA内でクォータ設定をしております。 > ただ、最初に解凍したように、RHEL6 では noatime を設定しても > 効果はほとんど無いですよ。 > > 私も過去にパフォーマンス検証しましたが、RHEL6 の環境では > noatime の有無では有意義な差は確認できませんでした。 > > このあたりの検証をしてくれている方のブログがありましたので > 参考までに。(ちょっと古いですが) > > http://shiumachi.hatenablog.com/entry/20080614/1213415948 パフォーマンス面ではどちらも差はなさそうですね。 現在atimeを使用しているアプリを使用していないので、 noatimeのままでも問題なさそうですが、今後を見据えてrelatimeも検討したいと思います。 色々とご助言頂きまして、ありがとうございました。 以上、よろしくお願いします。 -------------- next part -------------- HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...Descargar
Fork