GNU bug report logs - #50768
[PATCH] installer: Reorder file system type listbox.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 50768 <at> debbugs.gnu.org
Subject: [bug#50768] ext4 & btrfs
Date: Mon, 25 Oct 2021 11:29:54 +0200

Hello,

Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:

> Ludovic Courtès 写道：

[...]

>> What I do regularly see is rants about ext4 :-), which might be
>> justified, but in my many years with a store I have never had
>> problems
>> with ext4.  Also, the deduplication code gracefully handles ENOSPC
>> on
>> /gnu/store/.links.
>
> The kernel doesn't discriminate and logs warnings.

What do those warnings look like?

> Several people do notice these, don't realise that they are
> ‘harmless’, and follow some on-line tutorial to enable large_dir.
> Which apparently breaks GRUB.
>
> None of this is Guix's fault.  It does happen.

Oh, so it’s some tutorial out there that leads users to use ‘large_dir’
when they see those warnings?  Bah.

> I'm not happy with this patch: it's the tiniest possible tweak and
> puts a lot of implicit meaning into the default ordering.

Yeah.

That said, recommending btrfs (it’s now the first and default choice)
has implications.  It has its pros, but it doesn’t come for free either
in terms of usability and observable change in behavior in some cases.

For example, we’ll likely see reports of test suites that fail on user
machines (btrfs) but work on our build farms (ext4).

So I think we should be careful here.

Another option would be to document the ‘large_dir’ limitation, or to
use a newer GRUB if that limitation has been addressed in the meantime?

WDYT?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.