bug#30875: Garbage collector may leave empty files

bug#30875: Garbage collector may leave empty files

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#30875: Garbage collector may leave empty files

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> 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

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Marius Bakke <mbakke@fastmail.com> 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

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@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’.