bug#41710: Possibly found a bug while doing a "guix pull"

["Léon Lain Delysid" <leon.lain.delysid@gmail.com>]

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

That's really weird. I thought EXT3/4 was the best of the best? If the
files were user documents, I would be pissed. Well, we can't have perfect
computer programs out of the box.
And then again, I did say my system crashed in a very violent way (twice).
I had only one window open: the terminal with the "guix pull" running, but
it might have been some other program running in the background that froze
my system. The command was running, and then all of a sudden, the whole
system froze. The screen was frozen, the mouse, and even the keyboard. Then
after a minute, it rebooted by itself. That's a pretty violent crash.

On Wed, Jun 10, 2020, 15:25 Ludovic Courtès <ludo@gnu.org> wrote:

> Hello,
>
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
> > On Mon, 8 Jun 2020 01:15:46 +0200
> > Léon Lain Delysid <leon.lain.delysid@gmail.com> wrote:
> >
> >>or
> >> if my system crashing twice during a pull command somehow broke it,
> >
> > Probably.
> >
> >>but I
> >> hope this feedback helped.
> >
> > It sure helped.  It's good to know that that can happen.
> >
> > I remember the first time I used Guix, I picked some file system that
> would
> > keep doing that: leave empty files if the system crashed (among lots of
> other
> > things).  And that system crashed a lot.  I had the same result as you,
> > and a lot of additional problems.
> >
> > Back then we already improved a lot of places that were really really
> > important (added fsync calls), so the remaining places should be quite
> > harmless--like this one.  Because of Guix, you can always rebuild
> > /gnu/store just as it was--after a long build time maybe, but it's
> possible
> > (could be made a LOT more usable, though).
> >
> > (fsync degrades performance, so it makes no sense to fsync for
> /gnu/store)
> >
> > I think we can't really do more without imposing undue mainentance
> burden on
> > us (for something the file system shouldn't be doing in the first place),
> > or we could recommend another file system or different file system
> options
> > in the manual.  What would the latter be?
> >
> > Also, how it the world didn't the file system checker fsck
> >
> > (1) automatically run and
> > (2) fix this
> >
> > in your case?
>
> Yeah, that’s really weird.  I never experienced it first-hand, but it’s
> not the first time we have such a report.
>
> Ext4 & co. reportedly can leave empty files upon crashes; perhaps that’s
> a problem with those file systems (though I’ve always used ext2/3/4 and
> never had this problem myself, but that’s not statically significant).
>
> Anyway, closing.
>
> Thank you, Léon!
>
> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 3414 bytes --]