Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andreas Dilger <adilger@dilger.ca>
Mime-Version: 1.0 (1.0)
Subject: Re: [ANNOUNCE] e2fsprogs v1.46.0
Date:   Wed, 3 Feb 2021 04:43:00 -0700
Message-Id: <C19684EF-B868-4FDB-9145-F02844F8DB5C@dilger.ca>
References: <YBmMlwBaoC58CARb@mit.edu>
Cc:     linux-ext4@vger.kernel.org
In-Reply-To: <YBmMlwBaoC58CARb@mit.edu>
To:     Theodore Ts'o <tytso@mit.edu>
Precedence: bulk

On Feb 2, 2021, at 10:36, Theodore Ts'o <tytso@mit.edu> wrote:
>=20
> =EF=BB=BFI've released e2fsprogs 1.46.0 in all of the usual places;=20
>=20
> E2fsprogs now supports file systems which have both file system
> encryption and the casefold feature enabled.  This requires Linux
> version 5.10.

Gah!  I just noticed these patches being submitted to the kernel, but
they break the dirdata format in an incompatible manner. I hadn't been
paying close attention to casefold + encryption since I thought it was
only changing the hashing function and not the actual dirent format,
and I didn't see these patches to e2fsprogs being submitted to the
list (I couldn't find them in patchworks either).

Since this hasn't been landed to the kernel yet, and 1.46.0 was *just*
released, can we roll this back and instead make the extra hash stored
in a dirdata field? Preferably #3, since #1 is the Lustre FID, and #2 was
proposed for the high 32 bits of the 64-bit inode number (though it was
never landed and I don't think it is in use anywhere).

Having just looked at these patches for the first time, I can't say for sure=
,
but it looks like only a small on-disk format change would be needed to
make both features compatible with each other.=20

There would need to be a bit set in the dirent type field to indicate that
there is a hash stored after the name:

#define EXT2_DIRENT_HASH     0x40

and the length of the hash field would be stored as the first byte. Since th=
e
hash is stored aligned on a 4-byte boundary, the length is variable
(8+alignment), but storing the length at the start would not add any more
space for 3/4 of the names due to the existing padding for alignment.=20

Cheers, Andreas=