Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
2
Help us understand the problem. What are the problem?

More than 3 years have passed since last update.

@fujieda

Windows Subsystem for Linux (WSL)のreaddirはバグっている?

Windows Subsystem for Linux (WSL)のファイルシステムのベンチマークをBonnie++で取ろうとしたら、以下のようなエラーで中断してしまった。/homeの下でも/mnt/cの下でも同じ結果になる。

$ bonnie++
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty
Cleaning up test directory after error.

テストディレクトリを見ると、確かにファイルがたくさん残っている。Bonnie++はファイルのメタデータ操作の性能を測るために、16384(16*1024)個のファイルを作成するが、その半分くらいを消しそこねている。ファイルが何個残るかは試行によって微妙に変わる。

原因を調べてみたところ、Bonnie++がファイルを全部削除するときのロジックがbuggyであるというコメントをNFS-Ganeshaのissueで見つけた。Bonnie++は以下のロジックでファイルをすべて削除しているが、これがまずいとのこと。

opendir()
while (readdir())
    unlink();
closedir()

さらに調べると、macOSのHFSでも同じ問題が生じることがわかった。この記事では、ディレクトリに変更が加えられたあとにreaddirが何を返すかは未定義なので、このロジックではすべてのファイルを削除できないとしている。WSLのreaddirも同様に、ディレクトリに変更が加えられた場合に、すべてのエントリを読み出せるとは限らない実装になっているのだろう。

SUSv4のreaddirの仕様は、opendirのあとにファイルを追加や削除した場合、そのファイルをreaddirが返すかどうかを未定義としている。readdirの返値が未定義になるわけではない。追加・削除されたエントリを除くか含めるかは別として、readdirはすべてのエントリを読み出せなければならない。このロジックでファイルを全部削除できないreaddirの実装は、バグってるのではないだろうか。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
2
Help us understand the problem. What are the problem?