On 2025-04-08, Tobias Geerinckx-Rice wrote: > On 8 April 2025 16:48:37 UTC, Rutherther <ruthert...@ditigal.xyz> wrote: >>But on the other hand it's not responsibility of Guix to actually make >>sure the files are written to the disk itself. It just makes sure what >>currently is on the filesystem is fine. > > Anecdotally, empty store files happen a surprising lot. Surprising to > me, anyway. Not only on btrfs. > > It's been ages since I've used anything but Guix, but is this failure > mode really as common with other package manglers? Does anyone have > anecdata to that effect?
I know in Debian dpkg makes fsync calls afer many operations... If guix does not already call fsync or related system calls ... maybe it should? If it already does, maybe there are more places where it should call fsync? There will certainly be a performance hit, as a tradeoff for increased reliability... it would not fundamentally solve the problem, but it might significantly reduce the risks. There is a library that vastly speeds up dpkg operations by essentially disabling fsync... for things like initial installs or ephemeral chroot environments, where the problems resulting from datta corruption are far less significant: https://www.flamingspork.com/projects/libeatmydata/ live well, vagrant
signature.asc
Description: PGP signature
