過去の桐井戸端ＢＢＳ　（桐ver.９）
20597 桐９、windows98とXPが混在したネットワーク上でファイルが壊れるようになった knz 2003/05/28-14:06
パソコンの台数を増やしたときに、それまでのネットワークのWindows98マシンにWindosXPマシンを追加し、
それに伴い桐もVer.9にしたところ
共有更新で使っているファイルがひどいときには数時間ごとに壊れるようになり
k3に電話したところ、WindosXPとwindows98の混在で
ファイルが壊れる現象を確認していると言われました。

どなたか同じ現象になられた方はお見えになりませんでしょうか？
どちらかのＯＳに統一したら問題が起こらなければいいのですが。

とりあえず、Windows98の方をネットワークからはずして
数日間様子を見たいと思っています。
20601 Re:混在状況は異なりますが・・ MIT 2003/05/29-00:40
記事番号20597へのコメント
以下は事例として経験した事ですが

サーバーＯＳ：WinNT4.0_Server_SP6
クライアントＯＳ：Win98SE、Win2000Proの混在
クライアント数：２０台程度
桐バージョン：Ver8_SP6
通信プロトコル：TCP/IP

この環境でサーバーＯＳのみを

Win2000_Server

と変更したところ、共有する表が破損した事があります。
破損はクライアントＯＳがフリーズし、このクライアントを
リセットした時点で起こりました。
この破損は桐が用意している表の修復機能では修復出来ませんでした。

このシステムでは現在、サーバーＯＳをこれまでの

WinNT4.0_Server_SP6

に戻していますが、戻した後に共有する表の破損は
クライアントがフリーズして、それをリセットしても発生していません。
そもそも、サーバーＯＳが

WinNT4.0_Server_SP6

であった時に共有する表の破損は一度も発生していませんでした。
以上、事例としてご紹介します。MIT
20604 Re:混在状況は異なりますが・・ knz 2003/05/29-14:22
記事番号20601へのコメント
MITさんありがとうございます。

私の所では、
サーバー：LinuxのSamba
クライアントＯＳ：Win98SE、WinXP
桐９（SP1)
通信プロトコル：TCP/IP
です。

ファイルが壊れる状況ですが、ＯＳがフリーズするでもなく、
何の前触れもなく入力中にいきなり破損するという報告を受けています。
壊れた瞬間に他にどのクライアントで操作しているかというのは
ハッキリとは分かっていない状況です。
ただ、複数台でその表を操作していた可能性は非常に高いです。

以前クライアントがWinXPを除く構成（Win98SEのみ）では
問題なく稼働していました。
また、まだ丸１日だけではありますが、Win98SEを
ネットワークから除いた構成では、ファイルの破損は起こっていません。
ただ、まだ１日だけなので何とも言えませんが。

20605 Re:混在状況は異なりますが・・ hidetake 2003/05/29-16:11
記事番号20604へのコメント
>サーバー：LinuxのSamba

Samba とあったのでつい出てきました。　(^^;

ところで，Samba のバージョンは何ですか？

良くわかっておりませんが，Samba のバージョンによっては
Oplock の関係で，そのタイミングや手順の問題から，
ロックの解除でキャッシングの不整合からデータが壊れる場合もあったようです？

あと，ここでも前に出ましたが Oplock を無効にしたら，
どうなるかも興味あるところです。

ネットワークで桐を使うときのoplockの設定について
http://www.fuku3.com/~habata/kbbs/kakov8/18310.htm

ロックと Oplocks
http://www.samba.gr.jp/project/translation/using_samba/using_samba/ch05_05.html

あとは
http://cgi.samba.gr.jp/namazu.phtml?query=Oplock&submit=+%1B%24B8%21%3Aw%1B%28B+&whence=0&max=30&sort=score&reference=off&idxname=www.samba-jp


20610 Re:混在状況は異なりますが・・ knz 2003/05/30-10:58
記事番号20605へのコメント
hidetakeさんありがとうございます。
とっても勉強になりました。

>ところで，Samba のバージョンは何ですか？

2.0.5aだったと思います。
これまでは特に問題は起こっていませんでした。

>良くわかっておりませんが，Samba のバージョンに
>よっては Oplock の関係で，そのタイミングや手順
>の問題から，ロックの解除でキャッシングの不整合
>からデータが壊れる場合もあったようです？

確かに可能性はありそうです。
ただ、今回の現象はファイルにアクセス出来なくなったり、
フリーズすると言うことはなく、編集中に「ファイルが壊れています」
と出てきたり、次回開くと「ファイルが壊れています」状態になっています。
どうなのでしょうね。

ちなみにファイルの壊れ方は、修復したときのログによると
「ページ最大値が異常です」とのことです。
ほとんどの場合修復可能でした。

Windows98をネットワークかはずした状態で問題なく動いていましたが、
たまたま、規則を守らない人がいてついさっきWindows98を繋げて
操作をしたその瞬間にやはりファイルが壊れてしまったようです。

もう少し様子を見てみます。

20611 Re:混在状況は異なりますが・・ hidetake 2003/05/30-11:35
記事番号20610へのコメント
>>ところで，Samba のバージョンは何ですか？
>2.0.5aだったと思います。

結構古いですね！　(^^;

でも，私が気にしていたバージョンは 2.0.3以前 で
それよりは新しいわけで，危惧していた問題が直接
関係していたわけでも無さそうです。　(^_^ゞ

でも，Samba って使っているとやっぱいろいろあるわけで (;_;)　，
下記コメントをみても，いろいろあるようです。

旧 Samba サポート情報
http://www.samba.gr.jp/project/kb/J0/0/57.html

少なくとも Windows9x 系にはリダイレクタに
Oplock に関するバグはあるようですし？，Samba の
2.0.7 以前は Windows2000 系でも不具合は結構？
あるようです。

それでアップすれば改善できるかはわかりませんし，
この手の問題は NIC やタイミングの問題も絡んだり
で難しいですよね？　問題が出ない時は出ないし・・・


20615 Re:混在状況は異なりますが・・ hidetake 2003/05/30-13:31
記事番号20611へのコメント
もう少しというか，私の理解している範囲で oplock の
事を書いておきます。

oplock と言うのは「便宜的ロック」と言う意味で本来なら共有でファイルを開く場合，
自分だけでデータを専有しているわけでなく，いつサーバにあるデータが書き換えられるのか不定なので，
共有状態を無視したキャッシングや自分が持っていたキャッシング情報だけを元に
書き戻ししたらデータの不整合が発生するわけです。

ですから，本来はそのような状態にはならないようにするわけですが，
対象のファイルが他に誰も開いていない状態で，
自分が一番はじめに共有でファイルを開く場合に，
他の人がそのファイルを開くまでの間，便宜的に
ロックした状態でファイルを専有状態に近い状態で扱い
キャッシングし高速化を図れるようにする事が oplockの機能です。
もし，oplock 状態で誰か他の人が対象のファイルを開こうとしたら，
その新しくファイルを開こうとしている人にはちょっと待ってくれ共有のための処理をしていると
待機させ，oplock した人には共有で他の人もファイルを
使いたがっているので，今までのキャッシングを書き戻してくれ
oplock を解除するよ！と通信する。
これに従い，最初の人は自分で専有状態で使っていて
キャッシングされた内容をサーバ側と整合性が保たれるように必要に応じて
データの下記戻しを行い，それが終了された段階で NOS は oplock 状態を解除し，
本来の共有でみんながデータを扱えるようにする。

もし，このキャッシングと，oplock の手順やタイミング
に間違い(バグ)や不具合があるとデータに不整合が発生し，
さましく knz さんのような症状というか桐のデータの破損は発生しうると思います。

で，このような oplock の問題が本当に発生しうるか？
と言う事ですが，Microsoft の Network であれば，
このような状態が発生したら困るわけで，このような状態が
出ないような仕組みづくりは当然の事のように盛り込まれているでしょうし，
表には出ないような部分でも何かやっているのかも知れません。
それでも，過去には状態によっては不具合はあったようですし，
バグを含んだリダイレクタもあったようです。
Samba の場合も通常の場面であればこれらの機能は当然制御され機能しているわけですが，
クライアント側のバグや環境・状態によっては時として不具合が出る事もあるようです。
あるいは，MS の表には知られていない機能の
部分には対応しきれていないのかも知れません？

それと，最近のアプリ(特にMSのもの)はこの oplock を
アプリ自身でも制御しているようです。
でも桐はこの部分に関しては何もやっていないようです。
ですので，他のアプリでは症状が出なくても，
桐の場合は運が悪く症状が出てしまう事もあるかも知れません。

そう言う事もあって，ネットワークが不安定であったり，
わけのわからないデータ破損が発生するのなら，oplockをまず疑ってみる，
これを無効にしてどうなるかを確認する事は必要だと感じています。


20619 Re:混在状況は異なりますが・・ hidetake 2003/05/30-18:53
記事番号20615へのコメント
> oplock

Microsoft サイドの Oplock に関する説明です。

[PC Ext] Windows NT の Opportunistic Locking の説明
http://support.microsoft.com/default.aspx?scid=kb;JA;129202


20621 Re:混在状況は異なりますが・・ knz 2003/05/30-23:44
記事番号20619へのコメント
hidetakeさん、詳しいご説明ありがとうございます。
Sambaは、テスト環境充分もてず、バージョンを上げて良くなる可能性より
新たな問題が起こるリスクがあるので、
今回の問題がWindows98を除くことで解決するなら、
当面はそのままで行こうかとは思っていますが、変え時なのかもしれないですね。
K3でも問題は認識しているようなので、原因は探っているでしょうから
分かったら公開して欲しいです。

20622 Re:混在状況は異なりますが・・ hidetake 2003/05/31-08:11
記事番号20621へのコメント
knzさん，おはようございます。

今回の件は何も Oplock の関係と断定できるわけではありませんが
Oplock の関係が正常に動作しない環境であれば，
同様の状況が発生してもおかしくないと思って書いております。

で，もし Oplock の関係で，ファイルのロックの異常が発生したり
ファイルが壊れるような問題が発生した場合の対処方法に簡単に
まとめてみました。
---
Oplock 問題が発生した場合の対処方法？

１．クライアントのリダイレクタの更新(VREDIR.VXD)
　　Windows9x 最新のリダイレクタは Windows2000 Server の
　　Dsclient.exe 内に付属している。

２．Oplock の使用を無効にする

　■クライアント側で対処する場合(あまり進められない)
　・Windows9x系
　　[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VREDIR]
　　"DiscardCacheOnOpen"=string:00000001

　・WindowsNT系
　　[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\
Parameters]
　　"BufFilesDenyWrite"=dword:00000000
　　"BufNamedPipes"=dword:00000000
　　"UseOpportunisticLocking"=dword:00000000
　　"DormantFileLimit"=dword:00000000
　　
　　[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\
Parameters\Linkage]
　　"UtilizeNtCaching"=dword:00000000
　　
　　[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem]
　　"Win95TruncateExtensions"=dword:00000000
　　
　　[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\
Parameters]
　　"EnableOpLockForceClose"=dword:00000001
　　"EnableOpLocks"=dword:00000000

　■サーバ側で対処する場合

　・WindowsNT系
　　[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\
Parameters]
　　"EnableOpLocks"=dword:00000000

　・Samba
　　smb.conf : oplocks = False

　　あるいは oplock break wait time でタイミングの調整をする。
　　また，桐だけで問題が発生する場合 veto oplock files で桐関係の
　　ファイルだけ oplock を使わないようにする。
　　veto oplock files =
/*.tbl/*.wfm/*.rpt/*.cmd/*.kev/*.fsc/*.sem/*.txn/*.usr/*.rsc/
　　等々
---


戻る