Windows共有フォルダー上で動作が遅い件

[Kaz Nishimura]

ちょっと思い立って、TortoiseHgを使っている間のパケットをWiresharkで眺めていたんですが、stat辺りのエミュレーションなのか、同じファイルを何度も開き直すような挙動がありました。共有ファイルのアクセスについてはいろいろ無駄があるようですね。

追々いろいろ条件を変えて調べてみようと考えています。

[Katsunori FUJIWARA]

藤原です。

NFS 等でのファイル共有の場合、クライアント側で『属性キャッシュ

(atrfibute cache)』を保持することで、stat(2)等での通信頻度を低減せ

ていますが、SMB プロトコルで『ファイルプロパティのキャッシュ』につ

いて規定されたのは SMB 2.0 以降とのこと:

    http://www.atmarkit.co.jp/ait/articles/1304/25/news118.html

となると、クライアント／サーバの組み合わせ次第では、SMB 1.0 が選択

されることで、『プロパティ取得の際には都度 SMB プロトコルが飛んで

いる』可能性も考えられます。

＃ クライアントが対応していても、サーバが古いとキャッシュしない模様

もっとも、Samba の SMB 2.0 対応が 2011-08-09 リリースの 3.6 以後ら

しいので、全て Windows で揃えているか、比較的新しい Samba で運用し

ているなら、他に原因があるのでしょうねぇ。

    http://itpro.nikkeibp.co.jp/article/COLUMN/20111020/371120/

一応、Python のC実装部分をざっと見た限りでは、os モジュールの

stat() や lstat() といった POSIX 互換関数は、

Modules/posixmodule.c において posix_stat() や posix_lstat() とし

て定義されていて:

    http://hg.python.org/cpython/file/ab05e7dd2788/Modules/posixmodule.c

  os.stat() 呼び出し

  → posix_stat()@posixmodule.c

     →  posix_do_stat()@posixmodule.c

         → win32_stat()@posixmodule.c

            → GetFileAttributesExA()

               http://msdn.microsoft.com/ja-jp/library/cc429315.aspx

            ERROR_SHARING_VIOLATION 発生時:

            → attributes_from_dir()@posixmodule.c

               → FindFirstFileA()

                  http://msdn.microsoft.com/ja-jp/library/cc429233.aspx

という呼び出しフローになっています。

ERROR_SHARING_VIOLATION は:

    同一ファイルに複数のプログラムがアクセスしていることによるエラー

とのことですが、ファイル内容／属性情報の読み込みアクセスが並走した

程度でも発生するものなのかどうかは、私自身はよく分かってないので、

ご存知の方はお知らせ頂けると助かります。

GetFileAttributesExA()　が ERROR_SHARING_VIOLATION で失敗した場合

は、属性取得のために attributes_from_dir() 経由で

FindFirstFileA() を呼び出していますので、ERROR_SHARING_VIOLATION

発生の有無によって、原因は以下のような感じになるのではないかと思わ

れます。

  - ERROR_SHARING_VIOLATION が発生していない:

      GetFileAttributesExA() 呼び出しのみなので:

        - SMB/CIFS プロトコル、その実装、あるいは実行環境の問題:

          属性キャッシュ無しで都度通信が発生しているか、属性キャッ

          シュの有効期間が短すぎる

        - Mercurial の stat()/lstat() 発行が多過ぎる:

          ローカルファイルシステム(= カーネルレベルで属性がキャッ

          シュされる)ことを前提としているため

  - ERROR_SHARING_VIOLATION が発生している:

      FindFirstFileA() 呼び出しが発生するので、Windows API 呼び出

      しが2倍になる

ERROR_SHARING_VIOLATION が発生しないのであれば、POSIX 互換の

stat() 実現は特にオーバヘッド等があるようには見えませんね。

もっとも、Windows API 機能 ⇔ SMB リクエストのマッピングまでは確認

してませんので、１つの Windows API 呼び出しが複数リクエストに分解

されている可能性も無くはないですが、さすがにそこまでアホな仕様には

なっていないと思いたいです（笑） ＞ SMB

2013年7月2日 15:16 Kaz Nishimura <kaz...@vx68k.org>:

ちょっと思い立って、TortoiseHgを使っている間のパケットをWiresharkで眺めていたんですが、stat辺りのエミュレーションなのか、同じファイルを何度も開き直すような挙動がありました。共有ファイルのアクセスについてはいろいろ無駄があるようですね。

追々いろいろ条件を変えて調べてみようと考えています。

--
--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
 
 

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

もしかしてと思って、Samba側でSMB2を有効化してみましたが、体感上ではあまり変わりませんでした。プロトコルレベルでチェックしたわけではないので、SMB2になっていない可能性はありますが。

前回取得したパケットをSMBのプロトコルレベルで見たときに、ところどころoplockを要求せずにオープンしているところがあり、これだとクライアント側でキャッシュされないんじゃないかと考えているところですが、Win32 APIとSMBとのマッピングも不明なので何が悪いのか判断するには情報が足りていません。

何かわかればまたご報告します。

このグループから退会し、メールの受信を停止するには、mercurial-ja+unsubscribe@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
 
 

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

仮説として、win32._getfileinfoでread/writeのいずれも指定しないでオープンしているのでoplockを要求せず、属性キャッシュも無効になっているということはあり得るでしょうか。

[Kaz Nishimura]

手元で少し試してみましたが、この仮説は外れっぽいです。

その一方で、どうもwin32.unlinkの処理で0.09秒ほど使っているような感じがあります。常時そうなのかまでは特定していませんが。renameの準備でディレクトリー階層をさかのぼって何か調べているようです。

[Katsunori Fujiwara]

藤原です。

Mercurial の Windows 環境における unlink 処理は、

POSIX 準拠な挙動にするために、少々手の込んだ処理をやっています。

http://selenic.com/repo/hg/file/725507cd5216/mercurial/win32.py#l344

ソースコード中のコメントにもありますが、Windows では open 中のファイルの

rename/unlink 周りが（POSIX 的な観点で）綺麗に動いてくれないためです。

2013年7月26日 23:32 Kaz Nishimura <kaz...@vx68k.org>:

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
 
 

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

それはわかるんですが、SMBのプロトコルレベルで見るとどうにも無駄が多いように見えるということで、何かうまく効率化する方法はないかというつもりで書いています。ファイル10個unlinkだけで約1秒というのはどうにかしたい。

[Kaz Nishimura]

参考として、unlink処理と見られる部分のSMB要求のトレースを載せておきます。

No.     Time        Source                Destination           Protocol Length Info
    233 1.945556    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     366    Create Request File: Documents\Projects\xllmnrd\src\ifaddr.c
    235 1.950006    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     350    Create Request File: Documents\Projects\xllmnrd\src
    237 1.953642    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     318    Create Request File: Documents\Projects\xllmnrd
    239 1.956976    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     180    Find Request File: Documents\Projects\xllmnrd SMB2_FIND_NAME_INFO Pattern: src
    241 1.960221    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects\xllmnrd
    243 1.963104    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     302    Create Request File: Documents\Projects
    245 1.966439    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     188    Find Request File: Documents\Projects SMB2_FIND_NAME_INFO Pattern: xllmnrd
    247 1.969356    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects
    249 1.972184    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     310    Create Request File: Documents
    251 1.975243    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     190    Find Request File: Documents SMB2_FIND_NAME_INFO Pattern: Projects
    253 1.978455    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents
    255 1.981284    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects\xllmnrd\src
    257 1.984503    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     292    SetInfo Request FILE_INFO/SMB2_FILE_RENAME_INFO File: Documents\Projects\xllmnrd\src\ifaddr.c NewName:Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1
    259 2.011480    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     182    GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: Documents\Projects\xllmnrd\src\ifaddr.c
    261 2.015911    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects\xllmnrd\src\ifaddr.c
    263 2.018740    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     382    Create Request File: Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1
    267 2.023801    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1
    271 2.030597    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     382    Create Request File: Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1
    273 2.034954    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     175    SetInfo Request FILE_INFO/SMB2_FILE_DISPOSITION_INFO File: Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1
    275 2.051904    2002:b4eb:feac:200:3c 2002:b4eb:feac:200:22 SMB2     166    Close Request File: Documents\Projects\xllmnrd\src\ifaddr.c-63e449c1

[Kaz Nishimura]

CreateFileしてからSetFileInformationByHandleでリネームとデリートすれば速くなるかと考えたら、この方法だとVista以降必須ですね。

[Kaz Nishimura]

先にデリートしてからリネームだと問題があるでしょうか。

[Katsunori Fujiwara]

藤原です。

2013年7月27日 18:57 Kaz Nishimura <kaz...@vx68k.org>:

> 先にデリートしてからリネームだと問題があるでしょうか。

先に『デリートを実施』した場合、mercurial/win32.py での unlink()
の コメント中にある、以下の『ゾンビファイル』問題が発生する契機に
なるのではないでしょうか？

    http://selenic.com/repo/hg/file/725507cd5216/mercurial/win32.py#l344

      - Calling os.unlink on a file that has been opened with Mercurial's
        posixfile (or comparable methods) will delay the actual deletion of
        the file for as long as the file is held open. The filename is blocked
        during that time and cannot be used for recreating a new file under
        that same name ("zombie file"). Directories containing such zombie files
        cannot be removed or moved.

ちなみに、Unix 系 OS だと、unlink(2) も rename(2) も、ファイル名ベー
スで処理対象を特定することから、『デリートしてからリネーム』はでき
ませんが、Windows 上(SMB プロトコル固有？)でのデリートやリネームは、
ハンドル等の、名前以外の方法で対象の特定が可能なのでしょうか？

> > On Saturday, July 27, 2013 5:56:00 PM UTC+9, Kaz Nishimura wrote:
> >
> >  CreateFileしてからSetFileInformationByHandleでリネームとデリー
> >  トすれば速くなるかと考えたら、この方法だとVista以降必須ですね。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

Win32のDeleteFile関数は、すべてのオープンしているハンドルがクローズされたときに、当該ファイルが削除されるようにフラグを立てると仕様で書いてあることから、オープンされているファイルを削除した場合、クローズされるまでは名前でアクセスできる可能性があると思われます。

SMBプロトコル上では、削除も名前変更もオープンしたハンドルに対する操作になっているみたいですね。SetFileInformationByHandle関数を使えば、ハンドルに対して名前変更も削除フラグを立てるのもできるようですが、惜しいことにXPにはありませんでした。

[Yuya Nishihara]

On Sat, 27 Jul 2013 07:50:00 -0700 (PDT), Kaz Nishimura wrote:
> Win32のDeleteFile関数は、すべてのオープンしているハンドルがクローズされたとき
> に、当該ファイルが削除されるようにフラグを立てると仕様で書いてあることから、
> オープンされているファイルを削除した場合、クローズされるまでは名前でアクセス
> できる可能性があると思われます。

結果として同名の CreateFile() 要求が失敗する事があるため、削除に先立って
使い捨てのファイル名へ改名しているのだと思います。

> The DeleteFile function marks a file for deletion on close.
> [...]
> Subsequent calls to CreateFile to open the file fail with
> ERROR_ACCESS_DENIED.

(http://msdn.microsoft.com/en-us/library/aa363915(v=vs.85).aspx より)

(ウィルススキャナ等の)他のプロセスがファイルハンドルを掴んでいたら起き得る
のかな?

> SMBプロトコル上では、削除も名前変更もオープンしたハンドルに対する操作になって
> いるみたいですね。SetFileInformationByHandle関数を使えば、ハンドルに対して
> 名前変更も削除フラグを立てるのもできるようですが、惜しいことにXPにはありませんでした。

Vista 以降でもパフォーマンスの優位性を説明できて、『ゾンビファイル』問題が発生
しないのであれば、修正が取り込まれる可能性はあると思います。
すぐにパッチが採用されることは無いでしょうが、恐らく誰か食いついてくるはず。

[Kaz Nishimura]

CreateFileが失敗するのが名前が残っているからであれば、まだその時点では名前変更も可能なんではないかという仮説です。POSIXではありえませんが、DeleteFileが最後のハンドルがクローズされたときに削除されるようにマークするという仕様どおりの機能であれば、そういうこともあるのではないかと。

DeleteFile直後にMoveFileして、ファイルが存在しないことでエラーになるなら、削除完了しているのでCreateFileも成功するだろう。MoveFileが成功するなら、その名前のファイルは存在しないのでCreateFileも成功するだろう、という予想です。

もし問題が生じるとすれば、MoveFileがファイルが存在しない以外の理由でエラーになるか、MoveFileが成功してもCreateFileがエラーになるかのいずれかが発生しうるということになるかと考えますが、何か見落としがあるでしょうかね?

[Yuya Nishihara]

On Sat, 27 Jul 2013 20:14:30 -0700 (PDT), Kaz Nishimura wrote:
> CreateFileが失敗するのが名前が残っているからであれば、まだその時点では
> 名前変更も可能なんではないかという仮説です。POSIXではありえませんが、
> DeleteFileが最後のハンドルがクローズされたときに削除されるようにマークする

> という仕様どおりの機能であれば、そういうこともあるのではないかと。
>
> DeleteFile直後にMoveFileして、ファイルが存在しないことでエラーになるなら、
> 削除完了しているのでCreateFileも成功するだろう。MoveFileが成功するなら、
> その名前のファイルは存在しないのでCreateFileも成功するだろう、という予想です。
>
> もし問題が生じるとすれば、MoveFileがファイルが存在しない以外の理由でエラーに
> なるか、MoveFileが成功してもCreateFileがエラーになるかのいずれかが発生しうる
> ということになるかと考えますが、何か見落としがあるでしょうかね?

MSDN の MoveFile の仕様からはハッキリした事が分かりませんので、とりあえず
試してみるのがいいんじゃないでしょうか。それが期待通りに動いて、数字が良く
なるなら、詳細を詰める価値があると思います。

Mercurial のソースでは windows.rename, win32.unlink 関数が関連します。

[Kaz Nishimura]

以下の2.(c)のケースみたいでダメなようですね。別のやり方を探してみます。

http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows

[Kaz Nishimura]

別の方法を思い付きました。

CreateFile関数で、共有なし指定でオープンできれば、他にオープン中のハンドルがないはずなので、このときにFILE_FLAG_DELETE_ON_CLOSEを付けてやれば、そのまま消えてくれるのではないか、ということで。CreateFile関数が共有エラーになればオープン中のハンドルがあるので、これまでどおりのやり方を使うと。

名前変更しなくても安全に削除できる場合は直接削除することで、時間短縮しようという発想ですね。

http://msdn.microsoft.com/ja-jp/library/windows/desktop/aa363858.aspx

SetFileInformationByHandle関数はUnicodeバージョンしかないようなので、どうしようか悩んでいたら、使わなくても良さそうな方法が出てきました。効果があるようならパッチを作ってみます。

[Kaz Nishimura]

とりあえずでっち上げてみました。どこかに問題があるかもしれませんので、テストしてもらえるとありがたいです。

2013年9月9日月曜日 21時54分10秒 UTC+9 Kaz Nishimura:

[Shun-ichi Goto]

この件に関連するかもしれないバグ報告が出てますね
http://bz.selenic.com/show_bug.cgi?id=4070

XPだとそんなことはないのに、Win7だとSambaの共有ディレクトリアクセスで
めっちゃ遅くなるとのこと。

--
Shun-ichi GOTO

[Katsunori Fujiwara]

報告者のメールアドレスと、Nishimura さんのものと思しき twitter ア

カウントから察するに、issue 4070 自体が Nishimura さん自身による

報告ではないかと(笑)

2013年10月24日 13:06 Shun-ichi Goto <shunic...@gmail.com>:

--
--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Shun-ichi Goto]

2013年10月25日 0:26 Katsunori Fujiwara <flying...@gmail.com>:

> 報告者のメールアドレスと、Nishimura さんのものと思しき twitter ア
> カウントから察するに、issue 4070 自体が Nishimura さん自身による
> 報告ではないかと(笑)

あ、、、 orz

--
Shun-ichi GOTO

[Katsunori Fujiwara]

藤原です。

随分遅くなってしまいましたが、まずはパッチ内容を確認してみました。

実環境での動作確認はまだなのですが、『動作確認してから～』とかだと、
更に返信が遅れそうなので (^ ^ ;;;)、とりあえずコードを見た段階での
感想です。


修正内容の肝は:

    (1) 非共有指定で、_FILE_FLAG_DELETE_ON_CLOSE 付きの
        CreateFileA() が成功したら、CloseHandle() 契機で unlink さ
        れる筈なので、そのまま終了

    (2) 共有関連のエラー(_ERROR_SHARING_VIOLATION) 『以外』であれ
        ば、ファイルアクセスそのもののエラーなので、従来処理を実施
        しても意味が無いことから、例外を投げて終了

    (3) それ以外の場合は、従来の手順を踏襲

という理解でよろしいでしょうか？

Win32 API 周りは不案内なので、内容の判断には自信が無いのですが、ざっ
と MSDN の API 仕様を確認した範囲では、(1) の前提 (unlink 保証) が
確実 (OS障害時等を除く) なのであれば、現状の修正で妥当な気がします。

引き続き、時間を見つけて実環境での動作確認にも挑戦してみます。


なお、修正方法に関しては:

    fh = _kernel32.CreateFileA(f, 0, 0, None, _OPEN_EXISTING,
            _FILE_FLAG_OPEN_REPARSE_POINT | _FILE_FLAG_DELETE_ON_CLOSE, None)
    if fh != _INVALID_HANDLE_VALUE:
        _kernel32.CloseHandle(fh)
        return
    if ctypes.WinError().winerror != _ERROR_SHARING_VIOLATION:
        raise e

上記の処理を、既存の処理の前に『高速化用ショートカット』として追加、
という体裁にすれば、修正での差分量を減らせると思うのですが、どうで
しょうか？

現状の修正だと、肝の処理追加よりも、単純なインデント変更だけの方が
多いので、レビュアーにやさしくない(笑)印象です。

2013年10月17日 13:33 Kaz Nishimura <kaz...@vx68k.org>:

--

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

体裁については直しを予定してます

このグループから退会し、メールの受信を停止するには、mercurial-ja+unsubscribe@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

参考資料を共有しておきます。

http://download.microsoft.com/download/f/2/1/f2146213-4ac0-4c50-b69a-12428ff0b077/Optimizing_Applications_for_Remote_File_Access_Over_WAN.pptx

PowerPointファイルなのが心苦しいですが、23枚目からどんなメタデータがキャッシュされるかであるとか書いてあったりします。意外にキャッシュされる情報は少ないようです。

他にもパス名を使うAPIは内部で<Openｰファイル操作ｰClose>に分解される (ネット上を3往復する) ので、先にファイルハンドルを取得してそれを使うほうが良いだとかあって、本格的に高速化するのは大がかりになりそうで泣けてきます。

[Kaz Nishimura]

時間を空けてしまいましたが、最近の stable ブランチを対象に新しいパッチを作成しました。手元での実行時間の比較は以下のような感じです。

CreateFile() がディレクトリに対して失敗することを期待して、最近追加された isdir() のチェックも外してあります。

パッチ適用前:

Z:\tmp\xllmnrd>e:hg update --time -r null
0 files updated, 0 files merged, 36 files removed, 0 files unresolved
time: real 9.378 secs (user 0.281+0.000 sys 1.123+0.000)

Z:\tmp\xllmnrd>e:hg update --time -r default
36 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 5.432 secs (user 0.265+0.000 sys 0.749+0.000)

パッチ適用後:

Z:\tmp\xllmnrd>e:hg update --time -r null
0 files updated, 0 files merged, 36 files removed, 0 files unresolved
time: real 4.427 secs (user 0.281+0.000 sys 0.749+0.000)

Z:\tmp\xllmnrd>e:hg update --time -r default
36 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 4.418 secs (user 0.140+0.000 sys 0.593+0.000)

On Monday, November 11, 2013 12:56:25 AM UTC+9, Kaz Nishimura wrote:

体裁については直しを予定してます

[Kaz Nishimura]

本当は TortoiseHg でも確認したかったんですが、どうやるのかわからなかったんですよね。

[Katsunori Fujiwara]

藤原です。

性能改善効果までは確認してませんが、win32.unlink() レベルで期待通
りの動作となることを確認しました。

CIFS/SMB 共有で応答性能が改善されるのは嬉しいですね。

以下、気になった点を挙げておきます。


● 現状の実装だと、WindowsError が raise されるので、上位層で補足
   漏れが発生するかも？

    上位層は POSIX 仕様の OSError や IOError を想定しているので、
    OSError あたりで包みなおした方が良い気がます。

    ＃ mercurial/windows.py の posixfile() 参照


● ディレクトリへの適用時のエラーコードが微妙かも？

    ディレクトリに "_kernel32.CreateFileA()" を適用した場合のエラー
    コード(errno 値)が EACCESS(13) なのは、POSIX 仕様の EPERM(1)
    や、Linux 実装の EISDIR(21) とも違うので、もしかしたら、想定外
    のパスが通ってしまう可能性があるかもしれません。

    まぁ、現状では、EPERM/EISDIR エラーコードを見て云々な個所は無
    いので、大丈夫だとは思いますが、少なくとも、コミットログなりコー
    ドなりに、POSIX/Linux とは異なる旨を書いた方が良いと思います。

    ＃ コミッタの挙動確認の手間を省けますし…


● 性能計測結果に関しては、コミットログに記載した方が良いと思います。

    性能改善系の修正は、計測の難しいリファクタリング系の変更以外は、
    大抵「計測結果はある？」旨の返信が返ってきますので。


● 最終的に "os.path.isdir(f)" 検査を省略する場合、"We also
   expect we will fail to open a directory." に関しては、コミット
   ログにも記載した方が良いかもしれません。例えば:

      This patch also removes "os.path.isdir(f)" examination,
      because "_kernel32.CreateFileA()" should fail against
      existing directory.

2014年1月22日 22:18 Kaz Nishimura <kaz...@vx68k.org>:

--

from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Katsunori Fujiwara]

藤原です。

Mercurial 側に関しては、パッチ適用済み unlink() 相当の関数を定義す
るエクステンションを作成し、エクステンション有効時に、以下をパッチ
適用済み unlink() 参照に置き換えれば、TortoiseHg 同梱版でも、修正
確認ができると思います。

    mercurial.win32.unlink
    mercurial.windows.unlink
    mercurial.util.unlink

ソースを見る限りでは、TortoiseHg 側ではもっぱら os.unlink() を使っ
ている（+ 一時ファイル系の削除のみ）みたいなので、性能向上を確認す
る上では、Mercurial 側の差し替えだけで大丈夫かな？

2014年1月26日 12:21 Kaz Nishimura <kaz...@vx68k.org>:

--

from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

WindowsError が OSError のサブクラスであるということなので捕捉されるだろうという期待だったんですが、捕捉されませんかね?

エラーコードの違いに関しては、エラー処理中でディレクトリだったかチェックすることも可能かとは思います。揃えることが必ずしも必要でなければ、コメントで明記することにします。

[Kaz Nishimura]

見落としがありました。WindowsError の errno が Python 2.4 までと 2.5 以降で違うようですね。OSError で返す方が無難ではありそうです。

[Katsunori Fujiwara]

藤原です。

2014年1月27日 16:48 Kaz Nishimura <kaz...@vx68k.org>:

WindowsError が OSError のサブクラスであるということなので捕捉されるだろうという期待だったんですが、捕捉されませんかね?

エラーコードの違いに関しては、エラー処理中でディレクトリだったかチェックすることも可能かとは思います。揃えることが必ずしも必要でなければ、コメントで明記することにします。

おっと、失礼しました。例外クラスの階層関係までは確認してませんでした……orz

 エラーコードに関しては、私も Matt がどう判断するかわからないので、
情報として明記しておいて、判断を仰ぐ方が良いと思います。

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

追加情報として、Windows 上でディレクトリに対して Python そのままの os.unlink() を呼び出した時の errno の値は確認したところ 13 (EACCES) でしたので、EISDIR を返す必要はないかもしれません。

2014-01-27 Katsunori Fujiwara <flying...@gmail.com>

このトピックの登録を解除するには、https://groups.google.com/d/topic/mercurial-ja/exZauhXJLc0/unsubscribe にアクセスします。このグループから退会し、グループのすべてのトピックの登録を解除するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

[Katsunori Fujiwara]

藤原です。

この修正、既に devel-ml に投函されていたんですね。

Pierre-Yves David 氏からの返信にあるように、現在 Mercurial は 2.9

リリースに向けての code freeze 期間に入っています。

2.9 のリリースまでは、基本的にはバグ修正（＋ ドキュメント改善／翻

訳更新）しか受け付けないことになっていますので、ご注意下さい。

＃ code freeze 期間はメジャーバージョンの RC 版公開のちょっと前から開始

ちなみに、MIME のマルチパート／アタッチメント形式は嫌がられる

（「個々のパッチを切り出すのが面倒」と以前 Matt が言っていた記憶あ

り）ので:

  - パッチの投函には "hg email" (patchbomb エクステンション)を使う

  - マルチパート／アタッチメント形式にならないように、-a/--attach

    や -i/--inline は指定しない

  - コミットログ以外の説明（今回のケースなら性能改善値等）は別ファ

    イルに書いて、--desc FILE で指定

  - 0 番目のメールのサブジェクトは --subject で指定

といった感じにした方が、送る方も読む方も楽チンです。

2014年1月22日 22:18 Kaz Nishimura <kaz...@vx68k.org>:

時間を空けてしまいましたが、最近の stable ブランチを対象に新しいパッチを作成しました。手元での実行時間の比較は以下のような感じです。

--

from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。

このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

すぐに取り込んでもらおうとまでは考えてないんですが、テストが十分とは言えないので まず関心をもってもらうところから始めることにしました。

[Katsunori Fujiwara]

藤原です。

2014年1月28日 0:43 Katsunori Fujiwara <flying...@gmail.com>:

> この修正、既に devel-ml に投函されていたんですね。

> 

> Pierre-Yves David 氏からの返信にあるように、現在 Mercurial は 2.9

> リリースに向けての code freeze 期間に入っています。

> 

> 2.9 のリリースまでは、基本的にはバグ修正（＋ ドキュメント改善／翻

> 訳更新）しか受け付けないことになっていますので、ご注意下さい。

> 

> ＃ code freeze 期間はメジャーバージョンの RC 版公開のちょっと前から開始

> 

> 

> ちなみに、MIME のマルチパート／アタッチメント形式は嫌がられる

> （「個々のパッチを切り出すのが面倒」と以前 Matt が言っていた記憶あ

> り）ので:

> 

>   - パッチの投函には "hg email" (patchbomb エクステンション)を使う

> 

>   - マルチパート／アタッチメント形式にならないように、-a/--attach

>     や -i/--inline は指定しない

> 

>   - コミットログ以外の説明（今回のケースなら性能改善値等）は別ファ

>     イルに書いて、--desc FILE で指定

> 

>   - 0 番目のメールのサブジェクトは --subject で指定

> 

> といった感じにした方が、送る方も読む方も楽チンです。

一点補足です。以下の件を忘れてました……

    - 既に bugzilla に issue 登録済みの件なので、コミットログの最

      初の行(＝ サマリ行)の末尾に "(issue4070)" を追加

      http://bz.selenic.com/show_bug.cgi?id=4070

      ※ "1. Submission checklist" の #2

      http://mercurial.selenic.com/wiki/ContributingChanges#Submission_checklist

> 2014年1月22日 22:18 Kaz Nishimura <kaz...@vx68k.org>:

> 

> > 時間を空けてしまいましたが、最近の stable ブランチを対象に新しい

> > パッチを作成しました。手元での実行時間の比較は以下のような感じで

> > す。

> > 

> > CreateFile() がディレクトリに対して失敗することを期待して、最近

> > 追加された isdir() のチェックも外してあります。

> >

> > パッチ適用前:

> > 

> > Z:\tmp\xllmnrd>e:hg update --time -r null

> > 0 files updated, 0 files merged, 36 files removed, 0 files unresolved

> > time: real 9.378 secs (user 0.281+0.000 sys 1.123+0.000)

> > 

> > Z:\tmp\xllmnrd>e:hg update --time -r default

> > 36 files updated, 0 files merged, 0 files removed, 0 files unresolved

> > time: real 5.432 secs (user 0.265+0.000 sys 0.749+0.000)

> > 

> > パッチ適用後:

> > 

> > Z:\tmp\xllmnrd>e:hg update --time -r null

> > 0 files updated, 0 files merged, 36 files removed, 0 files unresolved

> > time: real 4.427 secs (user 0.281+0.000 sys 0.749+0.000)

> > 

> > Z:\tmp\xllmnrd>e:hg update --time -r default

> > 36 files updated, 0 files merged, 0 files removed, 0 files unresolved

> > time: real 4.418 secs (user 0.140+0.000 sys 0.593+0.000)

> > 

> > On Monday, November 11, 2013 12:56:25 AM UTC+9, Kaz Nishimura wrote:

> > 体裁については直しを予定してます

-- 

----------------------------------------------------------------------

FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

issue 4070 については事実誤認ということもあって INVALID になってますので、出すとすれば Windows 一般の改善提案として改めた方が良いかというつもりで触れないようにしましたが、どうするのが良いでしょうかね。

手元ではすでに一部修正を加えてたりしますが。

[Katsunori Fujiwara]

藤原です。

2014年1月28日 17:44 Kaz Nishimura <kaz...@vx68k.org>:

issue 4070 については事実誤認ということもあって INVALID になってますので、出すとすれば Windows 一般の改善提案として改めた方が良いかというつもりで触れないようにしましたが、どうするのが良いでしょうかね。

手元ではすでに一部修正を加えてたりしますが。

おっと、INVALID 化されたのを見落としてました……

添付されている測定値は、いかにも SMB/CIFS 共有している z ドライブ

上でのものですが、ローカルドライブでは、有意な性能改善は見られない

のでしょうか？

性能改善が SMB/CIFS 共有限定なら、「issue 4070 の修正」扱いで良

い気がしますが、INVALID 扱いのものを reopen するのもアレかなぁ、と

いう気も。

ローカルドライブ上でも性能改善が見られるのであれば、一般性の高い

「Windows での性能改善」扱いできますから、確かに、issue 4070 とは

別物として投函した方が良さそうですね。

-- 

----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

ローカルディスクだとファイルが少ないと差が出にくいということで、Mercurial のリポジトリでの計測例です。

パッチ適用前:

C:\Users\Kaz\hgtmp>e:hg update --time -r null
0 files updated, 0 files merged, 1036 files removed, 0 files unresolved
time: real 18.605 secs (user 0.764+0.000 sys 5.444+0.000)

C:\Users\Kaz\hgtmp>e:hg update --time -r 2.9-rc
1036 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 19.202 secs (user 1.903+0.000 sys 3.058+0.000)

パッチ適用後:

C:\Users\Kaz\hgtmp>e:hg update --time -r null
0 files updated, 0 files merged, 1036 files removed, 0 files unresolved
time: real 1.323 secs (user 0.437+0.000 sys 0.811+0.000)

C:\Users\Kaz\hgtmp>e:hg update --time -r 2.9-rc
1036 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 20.252 secs (user 1.716+0.000 sys 3.401+0.000)

アンチウイルスのスキャンが走っている状態での比較ですが、ファイル削除についてはそれなりに高速化しているのではないかと。

[Katsunori Fujiwara]

藤原です。

2.9-rc → null の全ファイル削除で、ローカルディスク上でもこれだけ

明確な差がつくなら、「Windows 上での性能改善」としても、かなりイン

パクトがあると思います。

なお、パッチ適用前後での「"hg update 2.9-rc" した状態からの "hg

update null"」性能の比較は、性能改善度合いの記録として、コミットロ

グに含めた方がよいと思います。

2014年1月31日 0:14 Kaz Nishimura <kaz...@vx68k.org>:

--

from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

性能改善は期待するところですが、副作用が十分確認取れていないのが気になってはいます。

[Kaz Nishimura]

賽は投げられた……ではなくて、フリーズ明けたようなのでパッチを投げました。

http://patchwork.serpentine.com/patch/3465/

今後どう転がるやら。

[Kaz Nishimura]

誰も反応を返してくれないのは こんなものなんでしょうか?

[Takumi IINO]

飯野です。

3週間くらい返信も無く放置された後、リリースの直前に取り込まれるという例が

結構有ります。

# MattがFacebookに入ってからこういうケースが増えた印象が有ります。

「何日も反応が無かったら、気軽に再送してくれ」と書いてあるので、

水曜日くらいまで待ってから再送してみると良いのではないでしょうか。

http://mercurial.selenic.com/wiki/ContributingChanges#Emailing_patches

2014年2月10日月曜日 11時24分06秒 UTC+9 Kaz Nishimura:

誰も反応を返してくれないのは こんなものなんでしょうか?

[Katsunori Fujiwara]

藤原です。

Windows 固有修正の場合、判断を下せる人の数が少ない、というのもある
と思います。

緊急性の高くない性能改善系修正は、どうしても後回しになってしまいま
すね。

暫く前は、「保留中パッチ」は Matt の inbox 管理がベースだったので、
静かに忘却されるケースも多々あったみたいですが、今は Patchwork と
いうサービスで受理状況が管理されるようになったので、放置からそのま
ま忘れられるケースは減ったと思います。

    http://patchwork.serpentine.com/project/hg/list/

飯野さんが書かれているように、「再送歓迎」なので、１～２週間程度経っ
て反応が全く無いようなら、再送してみるのも手かと。

2014年2月10日 11:40 Takumi IINO <trot.t...@gmail.com>:

--

from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、mercurial-ja...@googlegroups.com にメールを送信します。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[Kaz Nishimura]

どうやら承認された模様です。ご協力ありがとうございました。

これで次のバージョンの TortoiseHg も少しは快適になるかな と期待しつつも、CIFS で遅い原因はこれだけではないので、次のボトルネックを見つける探索を続けます、暇があれば。

余談ですが、Win32 での名前によるファイル操作は、内部動作的に オープン、ハンドルによるファイル操作、クローズに分割されているらしく、POSIX 的なファイル操作を気軽に使うと予想外に時間のかかることがあるみたいなんですね。困ったものです。

On Tuesday, July 2, 2013 3:16:05 PM UTC+9, Kaz Nishimura wrote:

ちょっと思い立って、TortoiseHgを使っている間のパケットをWiresharkで眺めていたんですが、stat辺りのエミュレーションなのか、同じファイルを何度も開き直すような挙動がありました。共有ファイルのアクセスについてはいろいろ無駄があるようですね。

追々いろいろ条件を変えて調べてみようと考えています。

[FUJIWARA Katsunori]

藤原です。

TortoiseHg で問題が発生するとの理由から、backout 要望が投函されてますね。

    http://selenic.com/pipermail/mercurial-devel/2014-May/058573.html

パッチ自体にはどういった問題が発生するのかといった情報が書かれていませんが、

TortoiseHg 開発側では発生する問題の現象等は把握されてます？ ＞ 西原さん

2014年2月20日木曜日 10時52分47秒 UTC+9 Kaz Nishimura:

[Yuya Nishihara]

On Sat, 3 May 2014 06:42:25 -0700 (PDT), FUJIWARA Katsunori wrote:
> TortoiseHg で問題が発生するとの理由から、backout 要望が投函されてますね。
>
> http://selenic.com/pipermail/mercurial-devel/2014-May/058573.html
>
> パッチ自体にはどういった問題が発生するのかといった情報が書かれていませんが、
> TortoiseHg 開発側では発生する問題の現象等は把握されてます？ ＞ 西原さん

windows.rename() で、 win32.unlink() 成功後の os.rename() が失敗した可能性が
あるかもしれないという話です。原因も再現性も不明です。

https://groups.google.com/forum/#!topic/thg-dev/D3Z1pRJmi0Q
https://groups.google.com/forum/#!topic/thg-dev/EKzdRl933C0
https://bitbucket.org/tortoisehg/thg/commits/ef778af80e48

Adrian はこの手の原因不明な Win32 特有の問題にウンザリしてるのだと思います。

[Yuya Nishihara]

On Sun, 4 May 2014 13:59:43 +0900, Yuya Nishihara wrote:
> On Sat, 3 May 2014 06:42:25 -0700 (PDT), FUJIWARA Katsunori wrote:
> > TortoiseHg で問題が発生するとの理由から、backout 要望が投函されてますね。
> >
> > http://selenic.com/pipermail/mercurial-devel/2014-May/058573.html
> >
> > パッチ自体にはどういった問題が発生するのかといった情報が書かれていませんが、
> > TortoiseHg 開発側では発生する問題の現象等は把握されてます？ ＞ 西原さん
>
> windows.rename() で、 win32.unlink() 成功後の os.rename() が失敗した可能性が
> あるかもしれないという話です。原因も再現性も不明です。

その後の議論によると、再現性はあるようです。手元の Windows XP (1 or 2 CPU)
で再現できなかったため、環境依存ではないかと思います。

TortoiseHg を使わなくても、何らかのファイル変更監視で同様の問題が起きうる
かもしれません。

[Katsunori Fujiwara]

藤原です。

2014年5月6日 22:28 Yuya Nishihara <yu...@tcha.org>:

取り込み予定のレビュー中パッチが取り込まれる clowncopter リポジト
リに、backout 実施パッチが取り込まれた模様なので、3.0.1 では元の実
装に戻りそうですね。

http://42.netv6.net/clowncopter/

但し:

> TortoiseHg を使わなくても、何らかのファイル変更監視で同様の問題が起きうる
> かもしれません。

という懸念もありますし、3.0.1 版が早期リリースされる保証もありませ
ん。

そこで、少々やっつけ感は溢れますが、Mercurial 3.0 on Windows 利用
者向けに、win32.unlink 実装を差し替えるエクステンションを作成して
みました。

https://bitbucket.org/foozy/hgext-old-win32unlink/overview

(日本語の簡単な説明はこちら)
https://bitbucket.org/foozy/hgext-old-win32unlink/src/2b7b8eb3bd1677baca832b272f19252fec14d020/README.ja.rst?at=default

このエクステンションを有効にすることで、アンチウィルス系ソフトのよ
うな、ファイル監視処理を併用している環境での問題発生を回避できる可
能性があります。

お気づきの点があれば、bitbucket の issue tracker なり、ML 宛てなり、
twitter の @flyingfoozy 宛てなりにお知らせください。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)