<tt><font size=2>&gt; From: Frederick Grose &lt;fgrose@gmail.com&gt;</font></tt>
<br><tt><font size=2>&gt; On Wed, Mar 6, 2013 at 3:59 PM, &lt;John.Florian@dart.biz&gt;
wrote:</font></tt>
<br><tt><font size=2>&lt;snip&gt;</font></tt>
<br><tt><font size=2>&gt; root@aos-61:46 # # Lets now make it all go wonky:
<br>
&gt; root@aos-61:46 # time dd if=/dev/zero of=/foo <br>
&gt; Bus error <br>
&gt; <br>
&gt; real &nbsp; &nbsp;1m15.775s <br>
&gt; user &nbsp; &nbsp;0m2.818s <br>
&gt; sys &nbsp; &nbsp; 0m24.129s <br>
&gt; root@aos-61:46 # <br>
&gt; root@aos-61:46 # ls /root <br>
&gt; -bash: /bin/ls: Input/output error <br>
&gt; root@aos-61:46 # df -h <br>
&gt; -bash: /usr/bin/df: Input/output error &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
&gt; root@aos-61:46 # mount &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
&gt; -bash: /usr/bin/mount: Input/output error &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
&gt; root@aos-61:46 # cat /proc/meminfo &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
&gt; -bash: /usr/bin/cat: Input/output error &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; <br>
&gt; <br>
&gt; Is this expected? &nbsp;Is there anything I can do, e.g., configuration-<br>
&gt; wise, that can prevent this? &nbsp;Ideally this would fail much like
any <br>
&gt; other full disk situation. &nbsp;I understand that the overlay consumes
<br>
&gt; space, i.e., memory, for this file growth, including file removals,
<br>
&gt; but I'd at least like to be able to remotely reboot a system when
in<br>
&gt; this state, however I can't even do that because the reboot command
<br>
&gt; will either return the same I/O error or it may succeed but get the
<br>
&gt; I/O error when systemd tries to read /usr/lib/systemd/system/reboot.target.
<br>
&gt; <br>
&gt; I dug around in bugzilla, but found nothing there. &nbsp;I can file
a <br>
&gt; bug, but which package is likely at fault here?<br>
&gt; --<br>
&gt; John Florian</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; See&nbsp;https://fedoraproject.org/wiki/LiveOS_image&nbsp;for some
background <br>
&gt; and potential workarounds.</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; --Fred&nbsp;--</font></tt>
<br>
<br>
<br><tt><font size=2>There's really not much on that page that helps me
here. &nbsp;I'm trying to use Live images for a mostly-stateless embedded
appliance OS deployed to hundreds or thousands of devices. &nbsp;I realize
that the COW design is always going to be limited, but a more graceful
failure mode is really needed, somehow. &nbsp;For our use, the biggest
gain in stability here actually comes from systemd's journal with its trim-before-write
approach instead of the legacy write now, trim asynchronously approach
we used to have. &nbsp;However, that only covers one specific use case:
logging. &nbsp;Writing to proper persistent storage allows me to avoid
the root file system overlay, but most of these embedded devices use CF
or SD cards for storage, which have limited write cycles that must be respected.</font></tt>
<br>
<br><tt><font size=2>Is there a way to implement an artificial capacity
limit that would prevent processes from exhausting the overlay so that
the reserve might be used for recording the event and rebooting back to
a safer state?</font></tt>
<br>
<br><tt><font size=2>At the very least, I think this page could benefit
from a little stronger, more explicit wording of this failure case. &nbsp;While
it talks a little about some work-arounds, it actually says very little
about why they are needed. &nbsp;Only in the &quot;Overlay Recovery&quot;
section does it hint at the crash potential.</font></tt>
<br><font size=2 face="sans-serif"><br>
--<br>
John Florian</font>
<br>