Ah, now I get your point.
This is of course a wholly reasonable approach as reading back the bits to verify only helps defend against ‘instantaneous’ failures and would seriously compromise performance. It would do nothing to defend against bit rot.
In the same vein, and as Peter points out to the OP, most software assumes that writes succeed and handle corrupted data when read. There really isn’t much else that makes sense as how does one recover from a failed write? Retry endlessly? Rollback a transaction by making more writes? No strategy obviates the need for a complete recovery strategy for reading corrupt data
Sent from Surface Pro
From: Mark Roddy
Sent: Wednesday, February 11, 2015 10:04 AM
To: Windows System Software Devs Interest List
the write head for rotating media does not stop to read the checksum bits for the write and verify that the bits all actually got written to the media correctly, instead the head just moves to the next scheduled sector and sprays some bits out there, hoping for the best. Almost all the time this just works, or the fact that it didn’t work is irrelevant.
Unless there is a catastrophic error condition, writes don’t fail. It is the reads that fail, and they do - that is typically how errors are discovered on disks.
Mark Roddy
On Wed, Feb 11, 2015 at 7:47 AM, Marion Bond wrote:
I don’t understand what you are trying to say here.
Sent from Surface Pro
From: Mark Roddy
Sent: Tuesday, February 10, 2015 10:21 PM
To: Windows System Software Devs Interest List
So, without actually doing the read from media there is no guarantee that the write, even with FUA, was successful. The disk hardware on rotating media cannot actually wait to test that writes succeeded, the test happens when a read fails. You can accommodate that either by paying the cost of the read or by replicating the write somewhere else.
Mark Roddy
On Tue, Feb 10, 2015 at 7:15 PM, Marion Bond wrote:
And what is FUA on read useful for? Buggy hardware caches perhaps?
Event Windows clustering shared quorum disks on a shared SCSI bus don’t need that
FUA on write however, it vital for applications like SQL server or anything else needing ACID properties
Sent from Surface Pro
From: Peter Wieland
Sent: Tuesday, February 10, 2015 6:42 PM
To: Windows System Software Devs Interest List
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
—
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
—
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
— 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
—
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
— 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