Date: Sat, 29 Jan 2022 15:29:39 +1100 From: peterj@freebsd.org To: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: bio re-ordering Message-ID: <YfTCs7j3TPZFcFCD@server.rulingia.com>
next in thread | raw e-mail | index | archive | help
--rR6QH3wdzVxX3Kxu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm working on a GEOM Gate network client to better handle high-latency connections and have some questions regarding bio ordering assumptions (alternatively, how much should I be able to re-order bio requests without breaking things). Within geom_gate, an incoming bio request is retrieved =66rom the kernel using a G_GATE_CMD_START ioctl, processed in userland (typically by forwarding it to a remote system) and then returned via a G_GATE_CMD_DONE ioctl. My GEOM Gate client can reorder requests quite aggressively and I suspect it's breaking some kernel assumptions regarding bio behaviour. The following questions assume that BIO_READ, BIO_WRITE and BIO_FLUSH are valid but BIO_DELETE isn't supported. a) In the absence of BIO_FLUSH operations, what (if any) are the limits on reordering operations? Given a block that initially contains A, followed by a write B, read and write C, is there any constraint on which content the read returns? b) Are individual BIO_READ and BIO_WRITE operations expected to be atomic with respect to other BIO_WRITE operations? Give 2 adjacent blocks that initially contain AB, and successive write CD, read and write EF operations to those blocks, is it expected that the read would return CD (or maybe AD or EF, assuming that's valid from the previous question) or could the write operations partially complete in different orders, resulting in something like AD, CF, EB etc? b) I assume that a BIO_FLUSH should not return DONE until all preceeding write operations have completed issued. Is it required that write operations issued after the BIO_FLUSH must not complete before the BIO_FLUSH completes? --=20 Peter Jeremy --rR6QH3wdzVxX3Kxu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmH0wq1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzT1bA/9FmUTKFrSbavulQ5V+0VUBKjSmEX5GHYL6TolX97z/I6VqkIgS/nOERBd mYrh7c2zyiaTskTc+ytwg5x3Q+6X0SuxpKQwEy5lgCrE1I8BzglVnrdVVqxRV41g X7aWyPAIDdDpjmWhXkS507ZNcgcAo7VeJQj5Gj9flXGdy1yGFTZdklHM+e8VYcsc scLkTs/U9ctqp8cgv8rm8MCJHcxjJLF2ByXXBRWSqQhiAiCxckCID/yyMekIykC9 G/hgnMELlcTJrKrxFwDnlixCu0Eue/tu7CdbS6xtBh83Wc8oSWFNtOYOT0In6b1Z 22PlrRZOng9gNrQ94pOqdBAstLMSolOBPbkmRbnz/v+ZITFJv1g2kYJEd7SkZ4FH XX5rRUMcEB0Bz33XKVVRkmfiyyKJhuxfAMxAljC70DUByRkkYoS1dCgJa88W9Hti 7wBpye3387eyvTw7fFQCuO8lQ2z5DpAS+MXg3spdShOsrqGYYn210N4uSUeVe0B7 dAOlEyNuYPaGVb12TB3+yr1qI7EWMg0PhzlGbIJg2nKkxq8brtOE1iz5tM3qGdbK guRaXfRn4a+mRqoLQTZexTZhfjLPqGhx2TWODo+H1750dNQ+nLxCGv6lIfuQvvAw IkMqVEcW2NrKMRiYcv2neqLNHenIXOFSQFVdOb59eOvgMGD8u6E= =PDCy -----END PGP SIGNATURE----- --rR6QH3wdzVxX3Kxu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YfTCs7j3TPZFcFCD>