Flush operations and block devices

[nohajc]

When I configure a disk backed by macOS block device and try to use it in read/write mode, I end up with the following error:

[2025-03-28T23:29:45Z ERROR devices::virtio::block::worker] error processing request: FlushingToDisk(Os { code: 25, kind: Uncategorized, message: "Inappropriate ioctl for device" })

It seems to come from here:

VIRTIO_BLK_T_FLUSH => match self.disk.cache_type() {
    CacheType::Writeback => {
        let diskfile = self.disk.file();
        diskfile.flush().map_err(RequestError::FlushingToDisk)?;
        diskfile.sync().map_err(RequestError::FlushingToDisk)?;
        Ok(0)
    }
    CacheType::Unsafe => Ok(0),
},

It happens with both /dev/rdisk* and /dev/disk* files.

I am able to make it work if I set CacheType to Unsafe but this is not exposed in the C API. Do you think it would be a good idea to do so, or is there any other way to address this?

Thank you.

[slp]

I see two options:

1. Introduce an krun_add_disk3 so users can set up CacheType manually.
2. On macOS, detect if the backend is /dev/rdisk* (I'm not sure if it would be safe doing it with /dev/disk* since it's buffered) and use CacheType::Unsafe automatically.

Personally, I'd prefer 2. Is there a way on macOS to detect if the backend is a raw disk beyond check the path name?

[nohajc]

I thought it would work with the buffered /dev/disk* but it gave me that same error. I'll investigate more. It can fail on the flush operation or the subsequent sync. Both return the same thing so I don't actually know yet which one is being triggered here.

Besides checking the path, you can check the file type which is a block device for /dev/disk* and a character device for /dev/rdisk*.

[slp]

In that case, I think the best approach is defaulting to CacheType::Unsafe if the path is /dev/rdisk* and the target is macos. Would you like to propose a PR doing that?

[nohajc]

Yes, I'm going to open a PR. So, you'd prefer to match /dev/rdisk* path rather than any character device? Maybe there are other ways to detect this (I haven't really done any research yet) but I suppose the path should be a safe bet.

I could also find out how this works on Linux host to make a similar adjustment there as well.