[Discuss] systemd reboot
Richard Pieri
richard.pieri at gmail.com
Sun Mar 4 09:20:09 EST 2018
The old "sync;sync;sync;halt" mantra is folklore from the days before we
had a shutdown/reboot command which does this for us. The first sync
flushes any dirty buffers, the second blocks waiting for the first to
complete ensuring that there are no dirty buffers when the system goes
down, and the third... makes us feel good (it has no technical benefit).
This doesn't work as expected today because most drives lie about
committing writes to permanent storage. The second sync won't block
unless the size of data in dirty kernel buffers exceeds the drives'
write cache capacity and then it will block only long enough for that
ratio to flip. If the system restarts, loses power, whatever, when the
drives' on-board caches have not been committed then there will be data
loss. The Linux kernel code which guarantees that writes are committed
doesn't actually work because it relies on drives not lying about their
cache commits.
In which case the explicit sync in the script doesn't do anything in
terms of flushing data to disk. It does add a small delay between
running update-grub and the reboot which, I guess, gives your drives
enough time to commit their caches.
--
Rich P.
More information about the Discuss
mailing list