bug#46905: Add a note about ext4's dir_index to the manual

bug#46905: Add a note about ext4's dir_index to the manual

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Mainly a reminder to myself to do so.

Guix can break ext4, and more than once has, with a inscrutable 
error message.  We should document it explicitly.

See <http://logs.guix.gnu.org/guix/2021-03-03.log#220037>.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#46905: Add a note about ext4's dir_index to the manual

[Ludovic Courtès]

Hi!

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

> Mainly a reminder to myself to do so.
>
> Guix can break ext4, and more than once has, with a inscrutable error
> message.  We should document it explicitly.
>
> See <http://logs.guix.gnu.org/guix/2021-03-03.log#220037>.

You wrote:

--8<---------------cut here---------------start------------->8---
<nckx>OK, that's the culprit (it's common: ext4 has a design flaw in that it hashes directory entries and... just
dies when the hash table gets ‘full’). Try ‘tune2fs -E "hash_alg=tea" /dev/foo’ to select a different hash algo, or
‘tune2fs -O "^dir_index" /dev/foo’ to disable it completely if that doesn't help.
--8<---------------cut here---------------end--------------->8---

Really?  I’ve almost always used ‘dir_index’ in my Guix + NixOS days,
and IIRC store accesses were much slower before that was a thing.

On berlin, /gnu is a 37 TiB file system with ‘dir_index’ turned on and
it works well.

I don’t think we can claim there’s a design flaw.  WDYT?

Ludo’.

bug#46905: Add a note about ext4's dir_index to the manual

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

Hi Ludo'!

I should note that later in the IRC convo I corrected my sloppy 
‘full’ to ‘hash collision’.  Unfortunately it just returns an 
already overloaded -ENOSPC to user space.

Ludovic Courtès 写道：
> IIRC store accesses were much slower before [dir_index] was a 
> thing

Yes, it's a (t)horny dilemma :-/

> I don’t think we can claim there’s a design flaw.  WDYT?

Fine; implementation flaw, then?  Problem is, it's not like there 
are other implementations than the one we're stuck with, so it 
matters little what we call it.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#46905: Add a note about ext4's dir_index to the manual

[Ludovic Courtès]

Hi,

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

> I should note that later in the IRC convo I corrected my sloppy ‘full’
> to ‘hash collision’.  Unfortunately it just returns an already
> overloaded -ENOSPC to user space.

OK, but when do we get ENOSPC, then?

> Ludovic Courtès 写道：

[...]

>> I don’t think we can claim there’s a design flaw.  WDYT?
>
> Fine; implementation flaw, then?  Problem is, it's not like there are
> other implementations than the one we're stuck with, so it matters
> little what we call it.

My point is that we shouldn’t suggest that ext4 + dir_index is flawed
or unsuitable for Guix use, because we have strong evidence suggesting
otherwise.  :-)

Now, I agree that if there are bugs or limitations hit in some
situations, we should document (or fix) them.

WDYT?

Thanks,
Ludo’.

bug#46905: Add a note about ext4's dir_index to the manual

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

Tobias Geerinckx-Rice 写道：
> Mainly a reminder to myself to do so.

Update: I did a tiny bit of reading and came across the 
‘large_dir’ feature, which (as described) mitigates this problem 
somewhat.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]