How to verify file write to a physical hard disk

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

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

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.

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 :slight_smile: 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
>

@Mark Roddy:

I’m not sure disk.sys is ever setting FUA in its READ CDB.

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

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: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
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

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

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.

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

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:

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.

Sorry to be confusing. I said:

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

> 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

xxxxx@storagecraft.com

http://www.storagecraft.com