Date: Thu, 17 Jun 2021 10:19:02 +0100 From: Graham Perrin <grahamperrin@gmail.com> To: freebsd-questions@freebsd.org Subject: Safety harnesses (was: Is a successful call to write(2) atomic?) Message-ID: <a17cf47d-5aef-1623-46da-51c83054f083@gmail.com> In-Reply-To: <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org> References: <26258.1623802141@segfault.tristatelogic.com> <7801a6e8-2428-619e-5722-7317841595a1@qeng-ho.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/06/2021 14:17, Arthur Chance wrote: > … More like "we think the builders may have installed the floors in this > darkened building, but we suggest a flashlight and safety harness" … Vaguely related, from the perspective of someone who's not a developer, I was recently surprised by the potential downsides of defaults when FreeBSD is installed to UFS. For a moment, back to the opening post from Ronald F. Guilmette: >> … Is a block of data that is successfully written … The surprise, to me, was losing fifty-something seconds' worth of data in a kernel panic situation. Subsequently found, in the FreeBSD Handbook under '12.10.2. Soft Updates' <https://docs.freebsd.org/en/books/handbook/config/#soft-updates>: >>> … Soft Updates guarantee file system consistency in the case of a >>> crash, but could easily be several seconds or even a minute behind >>> updating the physical disk. If the system crashes, unwritten data >>> may be lost. … (I expected _some_ data loss, but sixty seconds surprised me.) It was suggested that disabling UFS soft updates might improve the situation. Through subsequent tests, with a disposable installation – soft updates disabled, carefully timed interruptions whilst using pkg-install(8) – I soon produced what seemed to be a wrecked base system. Photographs after the crash: <https://i.imgur.com/YdI3LSJ.png>; <https://i.imgur.com/EpRE8S1.png>; – and after booting from a usable operating system, to check then repair the file system: <https://i.imgur.com/L1YXVgT.png>; <https://i.imgur.com/g1cCy3l.png>; <https://i.imgur.com/ZaM1vvx.png>; With the file system repaired: still, the base system was broken. Metaphorically, dropped without a safety harness from a height of more than one floor :-) From this end result, I assume that: 1. for guaranteed file system consistency with UFS, soft updates may be _highly_ desirable, in some situations 2. some other approach should be taken to reducing the potential scope (sixty seconds) of data loss. --- Some surprise at the default delays for syncing files, directories and metadata. Respectively: 30, 29 and 28 seconds. syncer(4) <https://man.freebsd.org/syncer(4)>; ---- For the computer where I wrecked the file system, I imagine that (for a future test installation) this combination will be reasonable: - soft updates disabled - mount(8) option 'sync' set in /etc/fstab (does this reduce the risk of wreckage with soft updates disabled?) - reduced delays for syncer(4). That's my imagination, although honestly, the whole thing messed with my mind. I'm much happier to simply use OpenZFS (or ZFS).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a17cf47d-5aef-1623-46da-51c83054f083>