On 05/25, Chao Yu wrote: > On 2020/5/7 15:59, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > Rework f2fs's handling of filenames to use a new 'struct f2fs_filename'. > > Similar to 'struct ext4_filename', this stores the usr_fname, disk_name, > > dirhash, crypto_buf, and casefolded name. Some of these names can be > > NULL in some cases. 'struct f2fs_filename' differs from > > 'struct fscrypt_name' mainly in that the casefolded name is included. > > > > For user-initiated directory operations like lookup() and create(), > > initialize the f2fs_filename by translating the corresponding > > fscrypt_name, then computing the dirhash and casefolded name if needed. > > > > This makes the dirhash and casefolded name be cached for each syscall, > > so we don't have to recompute them repeatedly. (Previously, f2fs > > computed the dirhash once per directory level, and the casefolded name > > once per directory block.) This improves performance. > > > > This rework also makes it much easier to correctly handle all > > combinations of normal, encrypted, casefolded, and encrypted+casefolded > > directories. (The fourth isn't supported yet but is being worked on.) > > > > The only other cases where an f2fs_filename gets initialized are for two > > filesystem-internal operations: (1) when converting an inline directory > > to a regular one, we grab the needed disk_name and hash from an existing > > f2fs_dir_entry; and (2) when roll-forward recovering a new dentry, we > > grab the needed disk_name from f2fs_inode::i_name and compute the hash. > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > Reviewed-by: Chao Yu <yuchao0@xxxxxxxxxx> Thanks, but it's quite late to rebase stacked patches for this update when considering we have only 1 week for pull request. :) > > Thanks, > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
|