Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


How to verify file write to a physical hard disk

Itai_HandlerItai_Handler Member Posts: 26
Hi all,

I have a user mode process (written in C++) that needs to write a file to a local hard disk partition
and then verify that the file has been written to the physical media without errors.

Is this doable under Windows? How?

I ask the question in NTDEV because I know that hard disks have their own internal cache, so I
am worried that if I use the following sequence: [ write - flush - read - compare ], then the
read may return (at least some) data from the on-disk cache, and not from the physical media.
In case the physical media has errors, I will not be able to detect the corruption.

I think that if I can purge the on-disk cache then all the required data will be read from the
physical media. But I don't know how to do that.

I am aware that Windows has its own caching as well.

Thank you,
Itai Handler

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,162
    <quote>
    I know that hard disks have their own
    internal cache, so I
    am worried that if I use the following sequence: [ write - flush - read -
    compare ], then the
    read may return (at least some) data from the on-disk cache
    </quote>

    The best you can do (if you can even call it that) is to set both FILE_FLAG_WRITE_THROUGH *and* FILE_FLAG_NO_BUFFERING when you call CreateFile. If you do this, you don't even have to send the flush (though you might want to still do it, just for "completeness").

    FILE_FLAG_WRITE_THROUGH results in the FUA ("Force Unit Access") bit being set in the SCSI CDB. This instructs the disk to commit the write to the media.

    In point of fact, disks (or the drivers that interpret CDBs for specific types of storage adapters) may or may not pay any attention to the FUA bit. But, as I said, this is the best you can get and the *contract* with the drive is that if FUA (or the equivalent) is set, the write should be committed to the media at the hard drive level.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alex_GrigAlex_Grig Member Posts: 3,238
    FILE_FLAG_WRITE_THROUGH works even without FILE_FLAG_NO_BUFFERING. But if you want to read the data back for verification, you would not want NO_BUFFERING.

    I'm not sure if FUA in a write command guarantees that the read will get data from the media, not from the disk buffer.
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,761
    Application clients may use the force unit access (FUA) bit in the CDB of
    commands performing write or read operations to specify that the device
    server shall access the medium. For a write operation, setting the FUA bit
    to one causes the device server to complete the data write to the medium
    before completing the command. For a read operation, setting the FUA bit to
    one causes the device server to retrieve the logical blocks from the medium
    rather than from the cache. - T10.

    YMMV.

    Your disk will now be unusably slow :-) On the other hand your disk will
    fail much sooner.

    Mark Roddy

    On Tue, Feb 10, 2015 at 2:05 PM, wrote:

    > FILE_FLAG_WRITE_THROUGH works even without FILE_FLAG_NO_BUFFERING. But if
    > you want to read the data back for verification, you would not want
    > NO_BUFFERING.
    >
    > I'm not sure if FUA in a write command guarantees that the read will get
    > data from the media, not from the disk buffer.
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Alex_GrigAlex_Grig Member Posts: 3,238
    @Mark Roddy:

    I'm not sure disk.sys is ever setting FUA in its READ CDB.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,162
    <quote>
    I'm not sure disk.sys is ever setting FUA in its READ CDB.
    </quote>

    I traced this once, and it IS set correctly. Or, well, it WAS.

    Shove a SATA disk on a drive analyzer sometime, and sent it some FILE_FLAG_WRITE_THROUGH reads and writes. You *will* see FUA set, using standard Windows drivers and a commodity AHCI controller.

    I can also tell you with certainty that there are disks/controllers/drivers that do not honor the FUA bit correctly. But, as I said in my initial reply, that's really beyond your ability to control at that point and getting FUA set is the best you can do.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_WielandPeter_Wieland Member - All Emails Posts: 309
    I think the answer is that it was. I went to look since I couldn't remember what we used to do, but it doesn't look classpnp only sets FUA for WRITE requests. There is not an option, short of rolling your own CDBs, to force unit access on a read.

    -p

    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Tuesday, February 10, 2015 3:30 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] How to verify file write to a physical hard disk

    <quote>
    I'm not sure disk.sys is ever setting FUA in its READ CDB.
    </quote>

    I traced this once, and it IS set correctly. Or, well, it WAS.

    Shove a SATA disk on a drive analyzer sometime, and sent it some FILE_FLAG_WRITE_THROUGH reads and writes. You *will* see FUA set, using standard Windows drivers and a commodity AHCI controller.

    I can also tell you with certainty that there are disks/controllers/drivers that do not honor the FUA bit correctly. But, as I said in my initial reply, that's really beyond your ability to control at that point and getting FUA set is the best you can do.

    Peter
    OSR
    @OSRDrivers

    ---
    NTDEV is sponsored by OSR

    Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

    OSR is HIRING!! See http://www.osr.com/careers

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 461
    FILE_FLAG_WRITE_THROUGH will do the trick for you. It is VERY slow.

    On Tue, Feb 10, 2015 at 11:28 AM, wrote:

    > Hi all,
    >
    > I have a user mode process (written in C++) that needs to write a file to
    > a local hard disk partition
    > and then verify that the file has been written to the physical media
    > without errors.
    >
    > Is this doable under Windows? How?
    >
    > I ask the question in NTDEV because I know that hard disks have their own
    > internal cache, so I
    > am worried that if I use the following sequence: [ write - flush - read -
    > compare ], then the
    > read may return (at least some) data from the on-disk cache, and not from
    > the physical media.
    > In case the physical media has errors, I will not be able to detect the
    > corruption.
    >
    > I think that if I can purge the on-disk cache then all the required data
    > will be read from the
    > physical media. But I don't know how to do that.
    >
    > I am aware that Windows has its own caching as well.
    >
    > Thank you,
    > Itai Handler
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >



    --
    Jamey Kirby
    Disrupting the establishment since 1964

    *This is a personal email account and as such, emails are not subject to
    archiving. Nothing else really matters.*
  • Itai_HandlerItai_Handler Member Posts: 26
    Hi all,

    Assuming I use FILE_FLAG_WRITE_THROUGH, which results in a FUA sent to the disk
    after the file write operation, how can I verify that the physical media contains a good
    copy of the file?
    For example, if I try to write "ABC" to the file, and somehow "ACC" gets to the media,
    how can I detect this kind of error?
    If I try to read the file from the disk for this verification purpose, will the read return
    the data from the physical media ("ACC") or from the on-disk cache ("ABC")?
    I understand from Peter's message that FUA is not set during read operations so I believe that
    the disk is allowed to return the data from its cache.
    I am very curious how do backup software ensure that data is written correctly to the media.
    Do they assume that the disk cache is small enough? I saw that some disk drives have pretty big caches.

    Thank you,
    Itai Handler
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,162
    <quote>
    I am very curious how do backup software ensure that data is written correctly
    to the media.
    </quote>

    In my experience, MOST backup software doesn't care. Seriously.

    Backup software generally views media defects as "not my problem"... The backup media either is good or it isn't good. What people want are backups that are fast.

    Even NTFS doesn't attempt to solve this problem by the way. Who says that ANY file you write will be the same when you read it back?

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alex_GrigAlex_Grig Member Posts: 3,238
    @Peter:

    Are you saying that one a file opened with WRITE_THROUGH, FUA will be set on both WRITE and READ CDBs, and you observed that? Because your wording was a bit confusing.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,162
    <quote>
    Because your wording was a bit
    confusing.
    </quote>

    Sorry to be confusing. I said:

    <quote>
    I traced this once, and it IS set correctly. Or, well, it WAS.
    </quote>

    When I traced this, I saw FUA set on both READ and WRITE.

    In any case, Mr. Wieland seemed to indicate that he thinks it does *not* get set on READ.

    If folks are curious, this should be very easy to find out... if you don't have a drive analyzer, do it was BusTrace, or take an hour and write a simple filter driver.

    I apologize for not being able to look into this and get a definitive answer myself. I'm randomly curious at the outcome, but I'm really up to my ass in other project commitments right now.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > I am very curious how do backup software ensure that data is written correctly to the media.

    It mostly does not care, except using CRCs and MD5/SHA checksums.

    Mostly it provides the user/admin with a choice of whether the dst backup file is written cached or noncached. This is usually provided for perf fine-tuning. And yes, the checksums.

    And, if the cached file have not reach the media correctly, then the OS disk stack will log errors. This is a sign to immediately retry backup using the fresh new backup target drive.

    --
    Maxim S. Shatskih

    Microsoft MVP on File System And Storage

    [email protected]

    http://www.storagecraft.com
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 9-13 Sept 2024 Live, Online
Developing Minifilters 15-19 July 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online