[PATCH] installer: Reorder file system type listbox.

Recommending ext4 over btrfs is probably ill-advised nowadays. See the

regular bug reports about running out of /gnu/store directory entries,

for which the documented fix then breaks booting with GRUB.

Instead, just list regular file systems alphabetically. We can bikeshed

bcachefs later ;-)

Move second-class file systems like NTFS to their own section at the end

of the list.

LISTBOX-ITEMS.

---

gnu/installer/newt/partition.scm | 6 +++++-

1 file changed, 5 insertions(+), 1 deletion(-)

Hello,

On this front, a related issue has been ext4 and large directories in Guix. Namely, that /gnu/store/.links quickly has many, many files (I'm at 9.9 million right now). This leads to warnings on ext4 and usually one will find that enabling large_dir will increase the file directory cap. Unfortunately, that is not compatible with Grub. This is what happened to me and was a bit of a mess (I reinstalled with Btrfs), and I know you (Tobias) also saw this in this thread: https://lists.gnu.org/archive/html/help-guix/2020-06/msg00015.html

So to the patch at hand, I'm wondering if we should make a note of this in file system selection in the installer (and in the manual in a few places). I don't know the actual ramifications of getting those directory full warnings in ext4, but I can see it easily leading to a problem booting a system with large_dir, as happened to me. I've submitted a bug to Grub, though this is well known, without response in plans to support a 4-year-old ext4 option. Since we expect Guix to have this huge directory, at least currently, I think we could avoid this issue with some warnings.

Sorry if this is a little astray for this patch, but thought it would be good to bring up.

Thanks,

John

Hello,

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

I’ve seen Keyras mention such a problem here, but again, I have not seen

“regular bug reports”. Are there open bug reports about ext4 issues?

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.

Otherwise LGTM, thanks!

Ludo’.

Ludo',

Ludovic Courtès ???

I've seen enough. s/bug reports/worried questions, not always

prior to messing with file system options/ for accuracy.

As in issues: no idea. I would expect them to be closed, so it's

not much of a metric.

The kernel doesn't discriminate and logs warnings. 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.

I'm not happy with this patch: it's the tiniest possible tweak and

puts a lot of implicit meaning into the default ordering.

I didn't find a good way to dynamically display a description of

each file system, but I wouldn't know what kind of Newt UI

primitives/concepts to search for.

Kind regards,

T G-R

Hello,

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

[...]

What do those warnings look like?

Oh, so it’s some tutorial out there that leads users to use ‘large_dir’

when they see those warnings? Bah.

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