[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Léon Lain Delysid
Subject: bug#41710: Possibly found a bug while doing a "guix pull"
Date: Fri, 12 Jun 2020 11:55:05 +0200

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:

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:
>> 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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]