[PATCH 1/2] iohelper: skip lseek() and ftruncate() on block devices

Michal Prívozník mprivozn at redhat.com
Mon Aug 23 15:04:28 UTC 2021

On 8/23/21 4:38 PM, Simon Rowe wrote:
> O_DIRECT is under control of the caller (though the --bypass-cache option). I am running in a constrained memory environment and when I don't use O_DIRECT the dump stalls at 5% load av hits 41 and the system becomes unresponsive.

Fair enough. I thought that block devices are always opened without
poisoning host cache. If they aren't then you patch makes sense.
But, what is your kernel version? Hopefully it's not too old. Is it a
special block device or just some regular disk?

Looking into the kernel code, it does implement O_DIRECT for block

kernel.git $ git grep -npC10 "\.direct_IO" -- fs/block_dev.c
fs/block_dev.c=1682=static const struct address_space_operations def_blk_aops = {
fs/block_dev.c-1683-    .set_page_dirty = __set_page_dirty_buffers,
fs/block_dev.c-1684-    .readpage       = blkdev_readpage,
fs/block_dev.c-1685-    .readahead      = blkdev_readahead,
fs/block_dev.c-1686-    .writepage      = blkdev_writepage,
fs/block_dev.c-1687-    .write_begin    = blkdev_write_begin,
fs/block_dev.c-1688-    .write_end      = blkdev_write_end,
fs/block_dev.c-1689-    .writepages     = blkdev_writepages,
fs/block_dev.c:1690:    .direct_IO      = blkdev_direct_IO,
fs/block_dev.c-1691-    .migratepage    = buffer_migrate_page_norefs,
fs/block_dev.c-1692-    .is_dirty_writeback = buffer_check_dirty_writeback,
fs/block_dev.c-1695-#define     BLKDEV_FALLOC_FL_SUPPORTED                                      \
fs/block_dev.c-1696-            (FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |           \
fs/block_dev.c-1697-             FALLOC_FL_ZERO_RANGE | FALLOC_FL_NO_HIDE_STALE)
fs/block_dev.c-1699-static long blkdev_fallocate(struct file *file, int mode, loff_t start,
fs/block_dev.c-1700-                         loff_t len)

So it seems like your patch was correct after all. Would you like to
resend this in v2 (I understand that patch 2/2 needs a rework) or do you
want me to push this one right away?


More information about the libvir-list mailing list