ext4: include charset encoding information in the superblock
authorGabriel Krisman Bertazi <krisman@collabora.co.uk>
Thu, 25 Apr 2019 18:05:42 +0000 (14:05 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Thu, 25 Apr 2019 18:05:42 +0000 (14:05 -0400)
commitc83ad55eaa91c8e85dd8cc3b7b3485fac45ef7bf
tree6c10e8bab625a1643fc7ca468fa00b6f20899971
parente765b4abb2215b88f227e3bed7757474b6e77402
ext4: include charset encoding information in the superblock

Support for encoding is considered an incompatible feature, since it has
potential to create collisions of file names in existing filesystems.
If the feature flag is not enabled, the entire filesystem will operate
on opaque byte sequences, respecting the original behavior.

The s_encoding field stores a magic number indicating the encoding
format and version used globally by file and directory names in the
filesystem.  The s_encoding_flags defines policies for using the charset
encoding, like how to handle invalid sequences.  The magic number is
mapped to the exact charset table, but the mapping is specific to ext4.
Since we don't have any commitment to support old encodings, the only
encoding I am supporting right now is utf8-12.1.0.

The current implementation prevents the user from enabling encoding and
per-directory encryption on the same filesystem at the same time.  The
incompatibility between these features lies in how we do efficient
directory searches when we cannot be sure the encryption of the user
provided fname will match the actual hash stored in the disk without
decrypting every directory entry, because of normalization cases.  My
quickest solution is to simply block the concurrent use of these
features for now, and enable it later, once we have a better solution.

Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fs/ext4/ext4.h
fs/ext4/super.c