Talk:Sugar on a Stick/Stick Layout

Current Discussion
Nothing has been edited on the StickLayout page for six months. Is there another place with more current discussion on this? -- Grantbow 20100927

Fedora Live USB write cache
livecd Digest, Vol 59, Issue 10

Message: 3 Date: Fri, 12 Mar 2010 08:23:46 +0000 From: James Heather  Subject: [Fedora-livecd-list] Write cacheing on a live USB stick (was:	Preventing access to /mnt/live (inter alia)) To: "livecd@lists.fedoraproject.org"  Message-ID: <1268382226.32238.53.camel@oscar.bluehouse.dyndns.org> Content-Type: text/plain; charset="utf-8"

Time to update you on my little experiments with write cacheing on a live USB stick.

It does look as though I'd misunderstood what the settings in /proc/sys/vm/ are for. I'd taken it that these just controlled paging of virtual memory (hence the 'vm'), i.e., writing to swap. But it seems that they also control the filesystem write cache. So I have stuck with ext4, and I now have in my kickstart:

%post cat >> /etc/rc.d/rc.local << EOF #more aggressive page writing in case of crash or power cut echo 500 > /proc/sys/vm/dirty_expire_centisecs EOF %end

which means that nothing is allowed to remain in the cache for more than 5 sec. (Strictly speaking, it is marked as dirty after 5 sec, and then gets written at the next wakeup, which happens every 5 sec by default; so in fact it can stay in the cache for up to 10 sec.)

Experiments suggest that this works nicely. I just wrote something like

for ; do date; sleep 1; done | tee logfile

and then yanked the USB stick out and rebooted it to see how much had been written; it wasn't ever more than a few seconds behind the terminal window. The LED also flashed briefly every 5-10 sec, which is what you'd hope.

This does seem more efficient than forcibly syncing every few seconds, which will work, but will also block disk reads during the sync process. It also means that the benefits of delayed allocation don't get seen.

Let's just hope nothing crashes during the real exam and it's all irrelevant!

James