Email list hosting service & mailing list manager

Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela (10 Jul 2019 18:51 UTC)
SQLite only SRFI? hga@xxxxxx (11 Jul 2019 01:49 UTC)
Re: SQLite only SRFI? John Cowan (11 Jul 2019 03:23 UTC)
Re: SQLite only SRFI? hga@xxxxxx (11 Jul 2019 08:19 UTC)
Re: SQLite only SRFI? John Cowan (11 Jul 2019 13:32 UTC)
Re: Systems lie about persistence and consistency promises. A lot. Arthur A. Gleckler (10 Jul 2019 22:51 UTC)
Schemepersist, anyone? hga@xxxxxx (10 Jul 2019 23:40 UTC)

Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela 10 Jul 2019 18:50 UTC

Ah, good old sync(2) :)

> ;;; Amazingly bogus syscall -- doesn't *actually* sync the filesys.
> (import-os-error-syscall sync-file-system () "scsh_sync")

> ;;; Amazingly bogus syscall -- doesn't *actually* sync the filesys.
> (import-lambda-definition-2 %sync-file-system (fd) "scsh_fsync")

Does anyone lurking here know what's the story with sync() now that SSDs
are gradually taking over?

IIRC sync() was always kind of a weird syscall because it basically
promises safety, but its behavior is so vague and complex that there's
no clear criteria for how applications should rely on that promise. In
practice, people resort to wishful thinking and do things like write a
hundred files calling sync() after each file, or calling sync() then
waiting a few seconds then calling sync() again to be sure. I've never
met anybody who can lay out a principled approach for how to use it.

The thing is, kernels typically sync() by themselves every 30-60 seconds
anyway, even if applications do not request it.