3 ms·

I am also curious. I tried asking Microsoft via Twitter and they asked me to copy the information from that Wiki page into Microsoft One Drive so they could re

I am also curious. I tried asking Microsoft via Twitter and they asked me to copy the information from that Wiki page into Microsoft One Drive so they could read it, and then suggested I try asking on Stack Overflow instead! https://twitter.com/windowsdev/status/989857799994822663 https://twitter.com/windowsdev/status/989857799994822663 Amusing social media exchanges aside, I'm quite curious to know as well. We don't have the answers for any non-open OS (though of course we can speculate about descendants of BSD except FreeBSD (probably throw away buffers on error), FreeBSD (probably keep buffers cached and dirty), and SysV systems (probably throw away buffers on error)). EDIT: They also suggested asking on MSDN Forums, which I didn't do because I don't have an account and am not a Windows developer at all, just a humble database hacker trying to understand how our stuff works on every platform. The code we committed assumes the worst by default, so not knowing the answer here isn't damaging. I dunno if it's possible to reach actual kernel hackers via MSDN Forums, but maybe someone should follow up with that. I think someone with the right skillset could possibly design an experiment to figure it out for Windows (several people have shown how to set up experiments on Linux and FreeBSD to test this).

mehrdadn 8y ago
Those tweets from Microsoft tick me off so much I might actually try to find a way to test this. I just don't have the time. But here's an idea that might work... anyone want to try it? Create a VM in VirtualBox and a .VMDK file that leaves some parts of the disk unmapped or read-only. Then try to write to it from inside the VM. It'll naturally fail (and the VM should give you an error) but you can continue and try flushing again, and see if it fails. If it does, then it re-tried the write. If not, then it didn't. To check, also test this on a Linux guest with fsync() to make sure it doesn't fail the second time. (Caveat: If the behavior differs depending on the particular error from the block device then you won't know. But it might be worth a try.)
- macdice 8y ago
  I don't know anything about Windows, but that seems like the right sort of approach; also is there such a thing as a network block layer you could temporarily break by disconnecting it? On other OSes there are fault-injecting drivers you can use to simulate IO errors. Maybe something like that exists? In fairness to the team handling their Twitter account, I recognise that it is completely the wrong forum to ask complicated kernel questions, it's impossible to get through the front-line silly question filter. (Try reporting a kernel bug to Apple; it seems to be impossible, they're all set up to receive bug reports about consumer UX stuff etc, there isn't even a drop-down option for "kernel", and reports complete with reproducers filed under "other" just linger unanswered. These mega-corps aren't like open source projects.)
  - rwmj 8y ago
    > is there such a thing as a network block layer you could temporarily break by disconnecting it Yes, nbdkit (assuming a Linux or BSD host for your VM) can do this kind of thing. I gave a talk about this topic at FOSDEM earlier this month: https://rwmj.wordpress.com/2019/02/04/video-take-your-loop-mounts-to-the-next-level-with-nbdkit/ https://rwmj.wordpress.com/2019/02/04/video-take-your-loop-m... The bit about testing is towards the end, but you may find the whole talk relevant.

mehrdadn 8y ago

Those tweets from Microsoft tick me off so much I might actually try to find a way to test this. I just don't have the time. But here's an idea that might work... anyone want to try it? Create a VM in VirtualBox and a .VMDK file that leaves some parts of the disk unmapped or read-only. Then try to write to it from inside the VM. It'll naturally fail (and the VM should give you an error) but you can continue and try flushing again, and see if it fails. If it does, then it re-tried the write. If not, then it didn't. To check, also test this on a Linux guest with fsync() to make sure it doesn't fail the second time. (Caveat: If the behavior differs depending on the particular error from the block device then you won't know. But it might be worth a try.)

macdice 8y ago
I don't know anything about Windows, but that seems like the right sort of approach; also is there such a thing as a network block layer you could temporarily break by disconnecting it? On other OSes there are fault-injecting drivers you can use to simulate IO errors. Maybe something like that exists? In fairness to the team handling their Twitter account, I recognise that it is completely the wrong forum to ask complicated kernel questions, it's impossible to get through the front-line silly question filter. (Try reporting a kernel bug to Apple; it seems to be impossible, they're all set up to receive bug reports about consumer UX stuff etc, there isn't even a drop-down option for "kernel", and reports complete with reproducers filed under "other" just linger unanswered. These mega-corps aren't like open source projects.)
- rwmj 8y ago
  > is there such a thing as a network block layer you could temporarily break by disconnecting it Yes, nbdkit (assuming a Linux or BSD host for your VM) can do this kind of thing. I gave a talk about this topic at FOSDEM earlier this month: https://rwmj.wordpress.com/2019/02/04/video-take-your-loop-mounts-to-the-next-level-with-nbdkit/ https://rwmj.wordpress.com/2019/02/04/video-take-your-loop-m... The bit about testing is towards the end, but you may find the whole talk relevant.