From nobody Sat Jan 29 04:29:39 2022 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7AF5519827A6; Sat, 29 Jan 2022 04:29:48 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jm1ZN20qhz3NnN; Sat, 29 Jan 2022 04:29:48 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643430588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=1e0nd+thODBC7fsExoX1j8LT6/YVvTRl61fD749DxW4=; b=x7EI5w5Hj3Bq3Oaj/thXRh2jMxApVc+Shi2oyldWcvC6M6B4LttK+FeoYGRTBuuY8TuMrH 4W0EakH+Cz45td9iGKJIBopnU17pzI9Vu9Mg0M6YjwmvqEdXWgh7RyaJkEdZdZOssvlDXu r8o/WX6H/5AIz09W7NJ4fNzeEojhqGV5Cn16khKEUO3nt/h9aj2QZwgWi61Idu6iSVNDmU p04/4gXiaAflJdIQqb0OtY8c3PfKTgtFdre9NVsD5VhSraox5vSkydBwJfhPFBp1uDbJyy 1OLEfuEo6ioXu0098ma5FUMPhdzntIIZunxK6Fyz9JObwzS9Rwj8WfuWJaNBrQ== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 244682592B; Sat, 29 Jan 2022 04:29:46 +0000 (UTC) (envelope-from peterj@freebsd.org) 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: List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rR6QH3wdzVxX3Kxu" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643430588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=1e0nd+thODBC7fsExoX1j8LT6/YVvTRl61fD749DxW4=; b=u2Fcj9G1WhMMQdsK+2CtYVrH0Bnxi/riKkpDBCv+VLAeCLue3rnw/dzihSdkCmaDtPr1Mp z6wBrEs2PIVxeObCFZ3DrNS6XlLM0ttwiPcDszgytGR6W4nKM2on4y+wU4jh3ANS/mWOPI Kw7typULxZm55IyQsYuSlHbB4r0bx0LaXt9nlDpz+KqkMvsMY2CS/ay05OXYXn3LCXOrdI ngxzibq2VFskqlC80LUWm2A9sDg2rRj6gBD3T6cndeR3IxrN7sX1MbB51bJ9gTnzIzcCP/ 3SO533Jd7cLyyf6mZIgiAJMrW5FNWh+JeN7e72ID/P4eA3WEz0fGu5NOzsMIdw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643430588; a=rsa-sha256; cv=none; b=tBSxVbMwRrnV8shzVDGW+70nMicx0DCk28Vwcf5kk/tU9Fc9Wwodsnde4/RCt89MyBKSMe s/EtuGcVzuCFyDhAmISDmu9rnCVHpsk4iKulA8kFEMAKW/1CKeoqYvUNQfpLqN6F42HtqA Tho7J4hOVvmY5jHIzCv/WtmaM0lcugJqJQMm8ftewnjfuT5UWC6OMoi7inGzRp2X3hfDgk Lb0cwNfr69Wck+qIEdkkGgp9v/octN3Bl+CNmfiYSWlQjerry5VJbul9CjHj+XR9et0F5z wsZM9lW2RfR4loj+Sxj3LFGigc4DMcA3B1lvZ196C+YzRkhTUqP2lz9CQw8ARQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --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--