none
シーケンシャルファイルの書き込みで、物理的に書き換えられるセクタ数は? RRS feed

  • 質問

  • ヒラマサと申します。
    過去ログに見つからなかったので、スレッドを立てさせていただきます。
    上手に検索すれば見つかるかも知れませんが。

    VBでもCでも構いませんが、テキストファイルをシーケンシャル(追記モード)で書き込みを行った場合、ファイルの最終位置にテキストが追記されます。

    VB6風に書けば、
    Open "Sample.txt" For Append As #1
              Print #1, "最後尾に1行追加"
    Close #1

    このファイルへの書き込みで、物理的にファイル全体を書き換えるのでしょうか?
    それとも、変化が起きた最後尾部分のセクタだけが書き換えられるのでしょうか?
    ご教示、お願いします。

    もっと具体的に書くと、2Kバイトのテキストファイルなら、ディスクの4セクタ(1セクタ=512バイト)を占めます。
    ファイルへの書き込みは、4セクタ全てが上書きされるのか、最後のセクタだけが上書きされ、先頭の3セクタには書き込まれないのか、ということです。

    純粋にソフトウェア上では、どうでも良いことですが、最近のフラッシュメモリを使ったDISKの場合には、書き込みサイズの大きさがDISKの寿命に関わってきます。

    蛇足ですが、フラッシュメモリを使ったDISKでは、デバイスの性質上、消去・書き込み回数に制限があります。
    この消去・書き込み回数を、DISK内蔵のコントローラーが管理して、空きエリアを有効にコントロールすることで長大な回数の書き込みを可能にしています。
    一例では、消去・書き込み回数が10万回のメモリデバイスを使用した1GBのフラッシュディスクに、128KBのファイルを読み書きすると、6億回以上の書き込みが可能です。(1GBのファイルなら10万回です)
    DISKの空き容量と、メモリの消去ブロックの大きさ、ファイルサイズで書き込みの回数上限が決定されます。

    以上、蛇足もありました。よろしくお願いします。

    2008年6月3日 8:53

回答

  • ツールを使って書き込まれたセクタを確認してみるのが良いと思います。

    確認できるかもしれないツールとしてsysinternalsのDiskMonを紹介しておきます。

     

    DiskMon

    2008年6月3日 13:29
  •  ヒラマサ さんからの引用

    このファイルへの書き込みで、物理的にファイル全体を書き換えるのでしょうか?
    それとも、変化が起きた最後尾部分のセクタだけが書き換えられるのでしょうか?

     

    厳密に言うなら、「不明」です。

     

    VB6のランタイム、I/OマネージャなどのOSのコンポーネント、

    ファイルシステムやディスクドライバ、ハードウェアなどが関連していますが、

    どれも「追記したように振舞う」ことを保証しているだけです。

     

    時と場合と、コンポーネントの実装次第で、

    実際にどうなっているのかは

     ヒラマサ さんからの引用

    純粋にソフトウェア上では、どうでも良いこと

    です。

     

    ファイルシステムレベルの話であれば、

    現行(XP,Vista)のNTFSではファイル全体を書き直すことはありえます。

    FastFatではたぶんありません。

    他のファイルシステムでは十分にあり得るでしょう。

    (それがないと機能しないファイルシステムもありますよね)

     

    ディスクドライバレベルでも、「全てから書き直す」という動作をするものはあります。

    ヒラマサさんが言っているように、ハードウェアレベルで位置を制御することもありえるでしょう。

    ですので、どの層を問題にしているのかを明示しなければ意味がありません。

     

    厳密でない話でいいなら。

     

    大抵の場合、最後のアロケーションユニットだけ書き直すとか、

    新しいアロケーションユニットを追加してそれだけ書く、

    という振る舞いになるでしょう。

    そしてそれは大抵の場合、最初から書き直すよりも速い動作になるでしょう。

    保証は全くありませんが。

    2008年6月3日 16:30
  • 寿命重視でWindowsにこだわらない、という条件であればLinuxにしてファイルシステムをJFFS2にするのも一つの手だと思います。
    2008年6月3日 22:20
  • C.Johnさん、れい さん、どうもありがとうございます。

    参考になりました。

    このフォーラムの利用は初めてですが、"回答済み"にチェックするので良いのですよね。

     

    次回、DiskMonで追ってみた結果を報告します。

    現在、フラッシュディスクへ書き込みを繰り返す実験を行なっていますが、Disk使用領域の増加が認められます。

    こちらの方からも、推定できれば報告します。

    (書き込みのキャッッシングをWindowsがどう行うのか、理解できていなので難しいかも知れません)

     

    JFFS2ファイルシステム、まさにフラッシュディスク向けファイルシステムですね。

    Windows以外の組み込みをする機会があったら試してみたいです。

     

     

    2008年6月4日 1:32
  •  ヒラマサ さんからの引用

    それにしても、WinXP ProfessionalでDiskMonを動かすと、"Write" のRequest だけがキャプチャーされます。

    USのMSDNフォーラムでも誰かが"Read"をキャプチャーできないとブツブツ言っていましたが、その人は解決していないようです。

    何かDiskmonのノウハウでもあるのでしょうか?

    手元のVistaとXPで動かしてみましたが、確かに私の環境でもXPはWriteのみですね。

    VistaではReadもキャプチャーされています。

    2000かVistaの環境が用意できるのであればそちらで確認してみるのが手っ取り早いかもしれません。

    2008年6月11日 12:12

すべての返信

  • ツールを使って書き込まれたセクタを確認してみるのが良いと思います。

    確認できるかもしれないツールとしてsysinternalsのDiskMonを紹介しておきます。

     

    DiskMon

    2008年6月3日 13:29
  •  ヒラマサ さんからの引用

    このファイルへの書き込みで、物理的にファイル全体を書き換えるのでしょうか?
    それとも、変化が起きた最後尾部分のセクタだけが書き換えられるのでしょうか?

     

    厳密に言うなら、「不明」です。

     

    VB6のランタイム、I/OマネージャなどのOSのコンポーネント、

    ファイルシステムやディスクドライバ、ハードウェアなどが関連していますが、

    どれも「追記したように振舞う」ことを保証しているだけです。

     

    時と場合と、コンポーネントの実装次第で、

    実際にどうなっているのかは

     ヒラマサ さんからの引用

    純粋にソフトウェア上では、どうでも良いこと

    です。

     

    ファイルシステムレベルの話であれば、

    現行(XP,Vista)のNTFSではファイル全体を書き直すことはありえます。

    FastFatではたぶんありません。

    他のファイルシステムでは十分にあり得るでしょう。

    (それがないと機能しないファイルシステムもありますよね)

     

    ディスクドライバレベルでも、「全てから書き直す」という動作をするものはあります。

    ヒラマサさんが言っているように、ハードウェアレベルで位置を制御することもありえるでしょう。

    ですので、どの層を問題にしているのかを明示しなければ意味がありません。

     

    厳密でない話でいいなら。

     

    大抵の場合、最後のアロケーションユニットだけ書き直すとか、

    新しいアロケーションユニットを追加してそれだけ書く、

    という振る舞いになるでしょう。

    そしてそれは大抵の場合、最初から書き直すよりも速い動作になるでしょう。

    保証は全くありませんが。

    2008年6月3日 16:30
  • 寿命重視でWindowsにこだわらない、という条件であればLinuxにしてファイルシステムをJFFS2にするのも一つの手だと思います。
    2008年6月3日 22:20
  • C.Johnさん、れい さん、どうもありがとうございます。

    参考になりました。

    このフォーラムの利用は初めてですが、"回答済み"にチェックするので良いのですよね。

     

    次回、DiskMonで追ってみた結果を報告します。

    現在、フラッシュディスクへ書き込みを繰り返す実験を行なっていますが、Disk使用領域の増加が認められます。

    こちらの方からも、推定できれば報告します。

    (書き込みのキャッッシングをWindowsがどう行うのか、理解できていなので難しいかも知れません)

     

    JFFS2ファイルシステム、まさにフラッシュディスク向けファイルシステムですね。

    Windows以外の組み込みをする機会があったら試してみたいです。

     

     

    2008年6月4日 1:32
  • DiskMonで書き込みの物理セクタを追ってみました。

    FAT32とNTFSでは、挙動が異なりますが、ファイル全体を書き換えていないことが分かります。

    ファイルシステムはFAT32にした方が単純なので追いやすいですね。

     

    しかし、セクタ単位まで細かく最適化して書き込むことでもないようです。

     

    VB6で下記コードを実行した場合
    Open "Sample.txt" For Append As #1
              Print #1, "最後尾に1行追加"
    Close #1

    ファイルサイズはどんどん大きくなり、100kバイト以上になっても、一回に書き込む大きさは、1~9セクタ長になります。

    1セクタ=512バイトなので、ファイルを4kバイト単位のブロックで管理して最後の変化の生じた部分の4kバイト以内の端数だけをセクタ単位で書き込んでいる様に見えます。

     

    推測ですが、DiskI/Oでは4kバイト=1クラスタとしてクラスタ単位の処理を行っており、変化の生じた最後の1クラスタを書き込んでいると理解すればよいかも知れません。

    ファイルシステムによってクラスタのサイズも異なるので、書き込みサイズも異なってくることが予想されます。

     

    それにしても、WinXP ProfessionalでDiskMonを動かすと、"Write" のRequest だけがキャプチャーされます。

    USのMSDNフォーラムでも誰かが"Read"をキャプチャーできないとブツブツ言っていましたが、その人は解決していないようです。

    何かDiskmonのノウハウでもあるのでしょうか?
    2008年6月11日 8:49
  •  ヒラマサ さんからの引用

    それにしても、WinXP ProfessionalでDiskMonを動かすと、"Write" のRequest だけがキャプチャーされます。

    USのMSDNフォーラムでも誰かが"Read"をキャプチャーできないとブツブツ言っていましたが、その人は解決していないようです。

    何かDiskmonのノウハウでもあるのでしょうか?

    手元のVistaとXPで動かしてみましたが、確かに私の環境でもXPはWriteのみですね。

    VistaではReadもキャプチャーされています。

    2000かVistaの環境が用意できるのであればそちらで確認してみるのが手っ取り早いかもしれません。

    2008年6月11日 12:12
  •  C.John さんからの引用

    VistaではReadもキャプチャーされています。

    2000かVistaの環境が用意できるのであればそちらで確認してみるのが手っ取り早いかもしれません。

    DiskMonのキャプチャー動作について、

    Windows2000は、大丈夫でした。("Read"/"Write"をキャプチャーできました)

     

    XP Profesionalでは、英語版以外でDiskMonに問題あるようです。

    MSDNライブラリから、WindowsXP Profesionalの英語版をインストールしてテストすると、ちゃんと"Read"/"Write"をキャプチャーしていました。

    2008年6月12日 10:06