--- /dev/null
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+<link rel="stylesheet" href="style.css" type="text/css"/>
+<script src="code.js" type="text/javascript"></script>
+
+<h1>Using qcow2 with NBD</h1>
+
+<p>
+ Filler - need to demonstrate:
+
+ <pre>
+ qemu -> (raw) -> qemu-nbd -> (qcow2) -> image.qcow2
+ qemu -> (qcow2) -> qemu-nbd -> (raw) -> image.qcow2
+ </pre>
+
+ maybe a table of pro/con for each
+
+<p>
+ Exposing qcow2 over NBD is too risky without resize, forcing
+ existing documentation to favor raw over NBD, even though this loses
+ out on the other benefits of qcow2.
+</p>
--- /dev/null
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+<link rel="stylesheet" href="style.css" type="text/css"/>
+<script src="code.js" type="text/javascript"></script>
+
+<h1>Tradeoff: Automatic or explicit</h1>
+
+<p>
+ Filler - need to demonstrate:
+ start with 1k image
+
+ <p>
+ Automatic (like file system):
+ <br>NBD_CMD_WRITE(offset=0,len=2k) -> success, size now 2k
+ <p>
+ Explicit (like block device):
+ <br>NBD_CMD_WRITE(offset=0,len=2k) -> fails
+ <br>NBD_CMD_RESIZE(2k) -> success, size now 2k
+ <br>NBD_CMD_WRITE(offset=0,len=2k) -> success
+</p>
--- /dev/null
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+<link rel="stylesheet" href="style.css" type="text/css"/>
+<script src="code.js" type="text/javascript"></script>
+
+<h1>Tradeoff: Simple or structured</h1>
+
+<p>
+ Filler - need graphics showing wire format of:
+
+<p>
+ Simple: 16-byte response, boolean answer
+<p>
+ Structured: 1 or more 20+-byte response
+ <br>Adding new NBD_REPLY_TYPE_RESIZE allows including updated size
+ in response
+</p>
--- /dev/null
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+<link rel="stylesheet" href="style.css" type="text/css"/>
+<script src="code.js" type="text/javascript"></script>
+
+<h1>Tradeoff: poll or notify</h1>
+
+<p>
+ Filler - need to demonstrate:
+
+<p>
+ polling (server cannot tell client about async changes unless client
+ polls):
+ <br>client: NBD_CMD_RESIZE(0)
+ <br>server: NBD_REPLY_TYPE_RESIZE response, including NBD_REPLY_DONE
+ <br>do stuff
+ <br>client: NBD_CMD_RESIZE(0)
+ <br>server: NBD_REPLY_TYPE_RESIZE response, including NBD_REPLY_DONE
+<p>
+ notify (client registers open-ended command to allow multiple async
+ server responses as needed):
+ <br>client: NBD_CMD_RESIZE(NBD_CMD_FLAG_NOTIFY)
+ <br>do stuff
+ <br>server: NBD_REPLY_TYPE_RESIZE response, excluding NBD_REPLY_DONE
+ <br>do stuff
+ <br>server: NBD_REPLY_TYPE_RESIZE response, excluding NBD_REPLY_DONE
+</p>
--- /dev/null
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+<link rel="stylesheet" href="style.css" type="text/css"/>
+<script src="code.js" type="text/javascript"></script>
+
+<h1>Tradeoff: how much complexity</h1>
+
+<p>
+ Filler - summarize various options. Maybe a 2-d graph with:
+
+ <pre>
+ c |
+ l |
+ ^ i |
+ e |
+ i n |
+ n t | multiple knobs,
+ c | requires multiple
+ r c | fallbacks, but a
+ e o | non-SR solution works
+ a m |
+ s p |
+ i l |
+ n e |
+ g x | require more uniformity,
+ i | interop testing is easier,
+ t | but writing correct server
+ y | requires more effort
+ +------------------------------------------------------
+ > increasing server complexity
+</p>
- based somewhat on https://lists.debian.org/nbd/2017/01/msg00016.html
-* Heading: Bigger is better?
+* Heading: Resize: where getting bigger is better
- 8000- slide
- qemu -> (raw) -> qemu-nbd -> (qcow2) -> image.qcow2
- qemu -> (qcow2) -> qemu-nbd -> (raw) -> image.qcow2