From: "Theodore Tso" <tytso@mit.edu>
To: Artem Blagodarenko <artem.blagodarenko@gmail.com>
Cc: linux-ext4@vger.kernel.org, adilger.kernel@dilger.ca
Subject: Re: [PATCH 0/3] Data in direntry (dirdata) feature
Date: Sat, 18 Apr 2026 20:47:16 -0400 [thread overview]
Message-ID: <20260419004716.GB58909@macsyma-wired.lan> (raw)
In-Reply-To: <CA+rD4x8uk7h7dv_Mg1tMXXiVZZD1YAj5WAw+6GNuMKQAAMueuQ@mail.gmail.com>
On Sat, Apr 18, 2026 at 11:24:32PM +0100, Artem Blagodarenko wrote:
> There is now a way to set dirdata. Following the decisions from [1]
> the patches provided change how the encryption + casefold
> hash is stored. If the dirdata feature is enabled,
> the hash is stored as dirdata. Therefore, to test dirdata, it is
> sufficient to test the combination of encryption + casefold + dirdata.
I'm not seeing that in the patches that was sent out to the list last
week. Where is that?
I traced all of the places where ext4_insert_dentry_data() and
ext4_dirdata_set() and I don't see *anything* where dirdata was
stored, including the fscrypt + casefold hash. What am I missing?
It *really* would be a good idea if the e2fsprogs patches included a
way to list and set the dirdata using debugfs. That way we could
easily verify that dirdata field was getting set when you expected it
to be.
> ext4/064: encryption + casefold (WITHOUT dirdata)
>
> This test verifies that files created in directories with both
> encryption and case-insensitive (casefold) attributes work correctly.
Yes, but that doesn't actually verify that the dirdata field was set
when you expected it to be. Just that it works correctly....
> LUFID is an optimization that allows Lustre to store file identifiers
> efficiently directly in directory entries, avoiding additional I/O
> operations to look them up separately.
Oh, I see. So this is for readdir(), right?
> I am open to adding mechanisms to access LUFID outside the Lustre
> filesystem. However, since: 1) dirdata is tested using the encryption +
> casefold features, and LUFID is primarily useful within the Lustre filesystem
> and is already tested there, I would prefer to rely on testing LUFID
> within Lustre FS.
Well, the one advantage of having a way to set and get LUFID would be
if you ever wanted to ressurrect the userspace Lustre server[1]. :-)
[1] https://wiki.lustre.org/images/5/56/LUG08-Lustre-uOSS.pdf
And I *do* think it would be useful to have a way to set and get the
LUFID using debugfs.
Cheers,
- Ted
next prev parent reply other threads:[~2026-04-19 0:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 21:37 [PATCH 0/3] Data in direntry (dirdata) feature Artem Blagodarenko
2026-04-17 21:37 ` [PATCH 1/3] ext4: make dirdata work with metadata_csum Artem Blagodarenko
2026-04-17 21:37 ` [PATCH 2/3] ext4: add dirdata support structures and helpers Artem Blagodarenko
2026-04-17 21:37 ` [PATCH 3/3] ext4: dirdata feature Artem Blagodarenko
2026-04-18 6:47 ` [syzbot ci] Re: Data in direntry (dirdata) feature syzbot ci
2026-04-22 9:34 ` Artem Blagodarenko
2026-04-22 10:09 ` syzbot ci
2026-04-18 21:43 ` [PATCH 0/3] " Theodore Tso
2026-04-18 22:24 ` Artem Blagodarenko
2026-04-19 0:47 ` Theodore Tso [this message]
2026-04-19 19:37 ` Artem Blagodarenko
2026-04-19 21:57 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260419004716.GB58909@macsyma-wired.lan \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=artem.blagodarenko@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.