Hello, Danny Milosavljevic <dan...@scratchpost.org> skribis:
> On Mon, 8 Jun 2020 01:15:46 +0200 > Léon Lain Delysid <leon.lain.dely...@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’.
