Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail From: Richard Kettlewell Newsgroups: comp.os.linux.misc Subject: Re: Shutdown - 25 Years Later Date: Sun, 20 Apr 2025 08:13:53 +0100 Organization: terraraq NNTP server Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6"; logging-data="1934"; mail-complaints-to="usenet@innmantic.terraraq.uk" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:v7BhE25O3HYPqXreOr1eStda9BI= X-Face: h[Hh-7npe<v9!1Z&W?r\c.!4DXH5PWpga"ha +r0NzP?vnz:e/knOY)PI- X-Boydie: NO Jim Jackson writes: > On 2025-04-19, Charlie Gibbs wrote: >> The story I heard was that typing "sync" three times takes long >> enough that the system has time to flush all its buffers before >> you do anything else. > > But sync shouldn't return until the buffers have flushed. > So repeats are not needed. sync is allowed to return before the flush has completed. See https://pubs.opengroup.org/onlinepubs/9699919799/functions/sync.html. On Linux (or any other sensible platform), with the normal user tools, no explicit syncs are needed at all. The normal shutdown process takes care of the whole question. The behavior of sync is irrelevant and any theory about needing typing sync even once is a myth. On other platforms, the same is usually true. The exceptions to this are: (a) An operating system that doesn’t guarantee clean shutdown in the same way. (Personally I’d consider that a bug.) (b) Directly issuing a reboot syscall (i.e. bypassing user commands like halt or systemctl), or interrupting power. Explicit syncs don’t help as much as you might hope here, for a couple of reasons: 1) As noted above, sync isn’t guaranteed to block until all data is flushed anyway; it’s allowed to return immediately, with any pending writes going on in the background. It happens that on Linux, sync _does_ block, so that’s not an issue for us, but on many platforms[1] it is not guaranteed to block. 2) Further writes may be initiated after the final call to sync (if nothing else, to update st_atime on /sbin/halt and its dependencies); no matter how many times you run it, even if you wait until the final sync completes, you still do not have a 100% guarantee about data persistence. In short there’s no number of syncs that will guarantee your data is all actually on disk. [1] Including FreeBSD, Darwin, HP-UX, OSF/1, Ultrix, SunOS, Solaris, V7 and at this point I stop looking. -- https://www.greenend.org.uk/rjk/