> On Aug 29, 2017, at 8:20 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Fri, Aug 18, 2017 at 12:19:42PM -0600, Andreas Dilger wrote: >> If there is a directory with more than EXT2_LINK_MAX (65000) >> subdirectories, but the DIR_NLINK feature is not set in the >> superblock, the feature should be set before continuing on >> to change the on-disk directory link count to 1. >> >> While most filesystems should have DIR_NLINK set (it was set >> by default for all ext4 filesystems, and the kernel before >> 4.12 automatically set it if the directory link count grew >> too large), it is possible that this flag is lost due to disk >> corruption or for an upgraded filesystem. We no longer want >> the kernel to automatically enable this feature. >> >> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=196405 >> Signed-off-by: Andreas Dilger <adilger@xxxxxxxxx> > > The f_large_dir test is now failing after I apply this patch: > > debugfs 1.43.6 (29-Aug-2017) > ./test_one: 38: /usr/projects/e2fsprogs/e2fsprogs/tests/f_large_dir/script: arithmetic expression: division by zero: "i / ELAPSED" > f_large_dir: optimize 3 level htree directories: failed You must have a faster test system than I do... I can send an updated patch with a fix for this, as well as the improvement for expand_dir as previously discussed. On a related note, I was trying to implement the optimization for more efficient ext2fs_link() insertion, but this has proven to be much more complex than I expected. I was thinking I would just call the link_proc() function directly to handle insertion of the new name, using block number of the previous caller. However, this function depends on the directory leaf buffers having been read from disk, and being passed a dirent pointer to the free space after being called through a series of callback indirections. I thought it would be a bit cleaner to call ext2fs_process_dir_block() (despite the warning that this function is for internal use only) with the previously saved block numbers, but that also depends on the dir_context state being initialzed, which didn't seem very clean. Am I doing down the wrong road here? Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
