OSDev.org

Hi,

I'm currently in a situation where I need to use interrupt 0x13 for read and write to a HDD. Apparently -- at least on many BIOS/controller/HDD-combinations -- there is no guarantee that data has actually been written when the interrupt returns. The writes are both being cached and reordered before they are finally written to the drive.

My quest is to find a way of causing the data to be flushed to drive, or at least find some way of knowing when and if the data has been written. Verifying sectors through interrupt 0x13 seems to funnily enough verify sectors in some cache somewhere. I was looking into using the legacy IDE interface, but this was shown to be near impossible since the HDD controller can be in AHCI mode. According to some documentation it can, on some controllers, still be possible to send ATA commands through the legacy IDE ports but this seems to be different on every controller. I am also unable to use AHCI since taking OS ownership would make it impossible to load a proprietary OS afterwards when it itself wants to take OS ownership on the AHCI controller.

Any ideas on things to try would be helpful, but I'm suspecting this will be nearly impossible by now.

Thanks,
Daniel

The write will be placed in harddisk's internal cache anyway.

Why do you need to ensure a write is physically written on storage? Usually you can recover power-failure with redundancy or other methods.

It's to guarantee consistency in a file system. Even with a journal, the commits might happen before some data is written, due to some cache in the chain reordering the writes. Redundancy would probably have to be through a log-structured FS, which is not impossible in my situation, but a way of flushing to disk would have been easier.

The short answer is that there is a FLUSH command you can issue to the drive.
The long answer is that there is a FLUSH command you can issue to the drive, and that some drives lie to you anyway.

Your best bet for guaranteeing consistency is to design your file system updates to happen "atomically" as much as possible.
The idea is to allocate and write out new/changed data in such a way that a final "commit write" of some kind needs to make
it to the disk in order for the changes to be finalized. Your commit write should be, if possible, the size of a single physical
sector. Because, "most" drives will promise at least the physical sector size will either be written completely or not at all.
This becomes easier with newer drives offering 4k native sector size.

linuxfood wrote:The short answer is that there is a FLUSH command you can issue to the drive.
The long answer is that there is a FLUSH command you can issue to the drive, and that some drives lie to you anyway.

Your best bet for guaranteeing consistency is to design your file system updates to happen "atomically" as much as possible.
The idea is to allocate and write out new/changed data in such a way that a final "commit write" of some kind needs to make
it to the disk in order for the changes to be finalized. Your commit write should be, if possible, the size of a single physical
sector. Because, "most" drives will promise at least the physical sector size will either be written completely or not at all.
This becomes easier with newer drives offering 4k native sector size.

Even if the HDD would respond to a FLUSH command, it seems like I have no way of sending it. Currently, commits can be written before all data is done since the writes are reordered by the cache. I guess the only solution is to never update data in place, as in a log-structured FS.

Thanks for the remarks, I think I have my answer.

Why on earth are you using int 13h when you're trying to write proper FS drivers? You should just write proper device drivers as well then.

Now it sounds like you're writing some kind of a bootloader. This is the only thing for which using int 13h makes sense. But why do you even need read/write FS drivers in a bootloader?