[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#50768] ext4 & btrfs
From: |
Ludovic Courtès |
Subject: |
[bug#50768] ext4 & btrfs |
Date: |
Mon, 25 Oct 2021 11:29:54 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello,
Tobias Geerinckx-Rice <me@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’.