bug#30875: Garbage collector may leave empty files
Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >> Are we sure this is a Guix issue and not a disk or file system >> corruption issue? The relevant code in guix-daemon hasn’t changed in >> ages. >> >> What file system are you using? Btrfs? :-) > > The ext[234] filesystems are well known for leaving zero-length files > around after a crash. So far, I've never seen Btrfs do that, and I > wouldn't expect it to based on its design. That's partly why I switched > to it. Sorry, I didn’t mean to imply that Btrfs is flawed. It’s just that I’ve never experienced that with ext[234]. Ludo’.
bug#30875: Garbage collector may leave empty files
l...@gnu.org (Ludovic Courtès) writes: > Marius Bakke skribis: > >> Recently I've seen a couple of instances like these: >> >> exporting path >> `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' >> guix offload: error: build failed: hash of path >> `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' >> has changed from >> `4223b4813b2253e68ea2b824d0d0e284ff75714ad0faf5a33d65a78df6b65915' >> to >> `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'! >> cannot build derivation >> `/gnu/store/jbx6a4n1d55dpydr87d11m7xwapm3pcx-gnome-3.24.3.drv': 1 >> dependencies couldn't be built >> >> Without the build hook, it manifests as: >> >> starting phase `unpack' >> tar: This does not look like a tar archive >> xz: (stdin): File format not recognized >> tar: Child returned status 1 >> tar: Error is not recoverable: exiting now >> >> There was another instance on help-guix recently with a user having >> empty .drv files in the store. >> >> There is a bug lurking here somewhere, but I'm not sure where to start >> looking. >> >> $ find /gnu/store/ -maxdepth 1 -size 0 | grep -v '\.lock$' | wc -l >> 24 > > Are we sure this is a Guix issue and not a disk or file system > corruption issue? The relevant code in guix-daemon hasn’t changed in > ages. > > What file system are you using? Btrfs? :-) The ext[234] filesystems are well known for leaving zero-length files around after a crash. So far, I've never seen Btrfs do that, and I wouldn't expect it to based on its design. That's partly why I switched to it. Mark
bug#30875: Garbage collector may leave empty files
Hello, Marius Bakke skribis: > Recently I've seen a couple of instances like these: > > exporting path > `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' > guix offload: error: build failed: hash of path > `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' has > changed from > `4223b4813b2253e68ea2b824d0d0e284ff75714ad0faf5a33d65a78df6b65915' to > `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'! > cannot build derivation > `/gnu/store/jbx6a4n1d55dpydr87d11m7xwapm3pcx-gnome-3.24.3.drv': 1 > dependencies couldn't be built > > Without the build hook, it manifests as: > > starting phase `unpack' > tar: This does not look like a tar archive > xz: (stdin): File format not recognized > tar: Child returned status 1 > tar: Error is not recoverable: exiting now > > There was another instance on help-guix recently with a user having > empty .drv files in the store. > > There is a bug lurking here somewhere, but I'm not sure where to start > looking. > > $ find /gnu/store/ -maxdepth 1 -size 0 | grep -v '\.lock$' | wc -l > 24 Are we sure this is a Guix issue and not a disk or file system corruption issue? The relevant code in guix-daemon hasn’t changed in ages. What file system are you using? Btrfs? :-) Thanks, Ludo’.
bug#30875: Garbage collector may leave empty files
Hello, Recently I've seen a couple of instances like these: exporting path `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' guix offload: error: build failed: hash of path `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' has changed from `4223b4813b2253e68ea2b824d0d0e284ff75714ad0faf5a33d65a78df6b65915' to `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'! cannot build derivation `/gnu/store/jbx6a4n1d55dpydr87d11m7xwapm3pcx-gnome-3.24.3.drv': 1 dependencies couldn't be built Without the build hook, it manifests as: starting phase `unpack' tar: This does not look like a tar archive xz: (stdin): File format not recognized tar: Child returned status 1 tar: Error is not recoverable: exiting now There was another instance on help-guix recently with a user having empty .drv files in the store. There is a bug lurking here somewhere, but I'm not sure where to start looking. $ find /gnu/store/ -maxdepth 1 -size 0 | grep -v '\.lock$' | wc -l 24 signature.asc Description: PGP signature
