• YumiYumiYumi@alien.topB
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    To see what ATTO is writing to the file, we wait until it has completed a write pass, and then cut power to the machine.

    I question how reliable this actually is. It might be fine, but I could see it not working as expected (e.g. OS didn’t flush all writes, or reverted something when rolling back the filesystem journal etc).
    Regardless, one would think that intercepting the WriteFile call and examining the buffer would be more reliable (or strip the FILE_FLAG_DELETE_ON_CLOSE flag when opening the file).

    • pcpp_nick@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Your point is a good one. Thanks for raising it.

      The combination of the observed file contents after several seconds of writing with the behavior difference in all 0s vs all 1s I/O in our fio experiments made me pretty confident about the conclusion we reached, but we should be sure.

      To be 100% certain, I just hooked CreateFileA to remove the FILE_FLAG_DELETE_ON_CLOSE. Examining ATTO’s I/O file after it completes shows that it does indeed contain only 0s.

      Tomorrow I can also try with ATTO hooked to write all 1s instead of all 0s to observe the performance difference directly in ATTO. (I’m away from the drives that exhibit the performance difference at the moment.)