Re: cache sync ioctl, freezes

[mlelstv%serpens.de@localhost (Michael van Elst)]

gdt%lexort.com@localhost (Greg Troxel) writes:

>Things are mostly ok, except:

>  - I get spurious DIOCCACHESYNC failed messages (below).  I think
>    that's because zvols don't support cache sync.  I don't know if this
>    is harmless or not.

That is mostly harmless, but may leave a disk in a less consistent
state than necessary when the system crashes.

For FreeBSD the code implements DIOCGFLUSH (the same operation),
so it looks trivial to also add DIOCCACHESYNC like:

diff -p -u -r1.13 zvol.c
--- zvol.c      29 Feb 2020 17:03:33 -0000      1.13
+++ zvol.c      2 Nov 2024 07:15:44 -0000
@@ -3638,6 +3638,10 @@ zvol_ioctl(dev_t dev, int cmd, intptr_t 
                break;
        }
 
+       case DIOCGSYNC:
+               zil_commit(zv->zv_zilog, ZVOL_OBJ);
+               break;
+
        default:
                dprintf("unknown disk_ioctl called\n");
                error = ENOTTY;


>  - If I run the system out of ram (by mallocing 8GB in a system with
>    6GB of RAM, and then writing to each page), the system freezes, by
>    which I mean an ssh session stops responding to CR and if I do e.g
>       echo 204500; date
>    typing that at 204500, then the date printed is usually 2 minutes
>    plus later.  (This happens without zfs loaded!)

Doesn't sound like a "freeze". Maybe system is (slowly) swapping?


>  - When I run a script that creates 10000 files in zfs, it runs
>    quickly, in seconds, maybe 10.  Trying to rm them takes over 5
>    minutes.   Keep in mind that the disk in the zpool in the domU is
>    backed by a zvol on the dom0.

That is an issue with our ZFS code. Removing files is a mostly
synchronous operation and that's not related to Xen or on what
device the data is backed, except that it's obviously worse on
slower devices.