GNU bug report logs - #46905
Add a note about ext4's dir_index to the manual

Previous Next

To reply to this bug, email your comments to 46905 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Bug reports for GNU Guix <bug-guix <at> gnu.org>
Subject: Add a note about ext4's dir_index to the manual
Date: Wed, 03 Mar 2021 22:08:16 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 46905 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 46905 <at> debbugs.gnu.org
Subject: Re: bug#46905: Add a note about ext4's dir_index to the manual
Date: Thu, 04 Mar 2021 23:01:26 +0100

Hi!

Tobias Geerinckx-Rice <me <at> 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’.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Bug reports for GNU Guix <bug-guix <at> gnu.org>
Subject: Re: Add a note about ext4's dir_index to the manual
Date: Thu, 04 Mar 2021 23:28:41 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 46905 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 46905 <at> debbugs.gnu.org
Subject: Re: bug#46905: Add a note about ext4's dir_index to the manual
Date: Thu, 04 Mar 2021 23:38:06 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 46905 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 46905 <at> debbugs.gnu.org
Subject: Re: bug#46905: Add a note about ext4's dir_index to the manual
Date: Mon, 08 Mar 2021 15:26:46 +0100

Hi,

Tobias Geerinckx-Rice <me <at> 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’.

Previous Next

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