From: Christoph Hellwig <hch@infradead.org>
To: Artem Blagodarenko <artem.blagodarenko@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu, jack@suse.cz,
adilger.kernel@dilger.ca, ablagodarenko@thelustrecollective.com
Subject: Re: [PATCH v13 00/11] Data in direntry (dirdata) feature
Date: Tue, 3 Nov 2026 06:37:55 -0800 [thread overview]
Message-ID: <aunxw4vjchztwQLG@infradead.org> (raw)
In-Reply-To: <20261029122413.230409-1-ablagodarenko@thelustrecollective.com>
I ended up here through the xfstests patches, because this looks like
a really weird feature. Unix directory entries aren't really standalone
objects. Why do you want to add more data for them and hugely
complicate the ext4 code?
There is this snipplet:
> The first user of this feature is LUFID (Locally Unique File ID), an
> identifier that must survive rename and be accessible from directory
> readdir without an inode lookup.
Which doesn't really explain anything. And unless things changes in
the last year, lustre used:
a) a kernel client making use of the file systems
b) used a heavily patched ext4 for that anyway
So why should upstream carry this stuff for something that is a
perpetually out of tree kernel consumer with a really odd architecture?
next prev parent reply other threads:[~2026-11-03 14:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 12:23 [PATCH v13 00/11] Data in direntry (dirdata) feature Artem Blagodarenko
2026-10-29 12:24 ` [PATCH v13 01/11] ext4: validate count against limit in ext4_dx_csum_verify/_set Artem Blagodarenko
2026-10-29 12:37 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 02/11] ext4: replace ext4_dir_entry with ext4_dir_entry_2 Artem Blagodarenko
2026-10-29 12:34 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 03/11] ext4: add ext4_dir_entry_is_tail() Artem Blagodarenko
2026-10-29 12:31 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 04/11] ext4: add dirdata format definitions and access helpers Artem Blagodarenko
2026-10-29 12:31 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 05/11] ext4: refactor dx_root to support variable dirent sizes Artem Blagodarenko
2026-10-29 12:49 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 06/11] ext4: add ext4_dir_entry_len() Artem Blagodarenko
2026-10-29 12:50 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 07/11] ext4: rename ext4_dir_rec_len() and clarify dirdata usage Artem Blagodarenko
2026-10-29 12:50 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 08/11] ext4: dirdata feature Artem Blagodarenko
2026-10-29 12:51 ` sashiko-bot
2026-10-30 9:29 ` kernel test robot
2026-10-29 12:24 ` [PATCH v13 09/11] ext4: add dirdata LUFID support for directory entry rename Artem Blagodarenko
2026-10-29 12:47 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 10/11] ext4: add dirdata set/get helpers Artem Blagodarenko
2026-10-29 12:44 ` sashiko-bot
2026-10-29 12:24 ` [PATCH v13 11/11] ext4: Add EXT4_IOC_SET_LUFID ioctl for setting LUFID on directory entries Artem Blagodarenko
2026-10-29 12:58 ` sashiko-bot
2026-10-30 12:21 ` kernel test robot
2026-11-03 14:37 ` Christoph Hellwig [this message]
2026-11-03 23:45 ` [PATCH v13 00/11] Data in direntry (dirdata) feature Artem Blagodarenko
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=aunxw4vjchztwQLG@infradead.org \
--to=hch@infradead.org \
--cc=ablagodarenko@thelustrecollective.com \
--cc=adilger.kernel@dilger.ca \
--cc=artem.blagodarenko@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox