The corresponding proposal to virtio-spec is here: https://lore.kernel.org/virtio-comment/20240618081858.2795400-1-keiichiw@xxxxxxxxxxxx/T/#t Best, Keiichi On Mon, Jun 17, 2024 at 12:34 PM Keiichi Watanabe <keiichiw@xxxxxxxxxxxx> wrote: > > Hi, > > I'm using ext4 over virtio-blk for VMs, and I'd like to discuss the > situation where the host storage gets full. > Let's say you create a disk image file formatted with ext4 on the host > side as a sparse file and share it with the guest using virtio-blk. > When the host storage is full and the sparse file cannot be expanded > any further, the guest will know the error when it flushes disk > caches. > In the current implementation, the VMM's virtio-blk device returns > VIRTIO_BLK_S_IOERR, and the virtio-blk driver converts it to > BLK_STS_IOERR. Then, the ext4 module calls mapping_set_error for that > area. > > However, the host's ENOSPC may be recoverable. For example, if a host > service periodically deletes cache files, it'd be nice if the guest > kernel can wait a while and then retry flushing. > So, I wonder if we can't have a special handling for host-side's > ENOSPC in virtio-blk and ext4. > > My idea is like this: > First, (1) define a new error code, VIRTIO_BLK_S_ENOSPC, in > virtio-blk. Then, (2) if the guest file system receives this error > code, periodically retry flushing. We may want to make the retry limit > via a mount option or something. > > What do you think of this idea? Also, has anything similar been attempted yet? > Thanks in advance. > > Best, > Keiichi
