diff options
| author | Dmitry Monakhov <dmonakhov@openvz.org> | 2016-09-05 23:38:36 -0400 |
|---|---|---|
| committer | Mister Oyster <oysterized@gmail.com> | 2017-12-31 01:44:56 +0100 |
| commit | 2832999d6ee7bfd2457a7c306d7cdb96222ff260 (patch) | |
| tree | b5d7fb90b30f2744eca645bc91c4e5df4d66dd0d /include/linux | |
| parent | d917c252432226b82956f20311caea1bfde0ac0a (diff) | |
ext4: improve ext4lazyinit scalability
ext4lazyinit is a global thread. This thread performs itable
initalization under li_list_mtx mutex.
It basically does the following:
ext4_lazyinit_thread
->mutex_lock(&eli->li_list_mtx);
->ext4_run_li_request(elr)
->ext4_init_inode_table-> Do a lot of IO if the list is large
And when new mount/umount arrive they have to block on ->li_list_mtx
because lazy_thread holds it during full walk procedure.
ext4_fill_super
->ext4_register_li_request
->mutex_lock(&ext4_li_info->li_list_mtx);
->list_add(&elr->lr_request, &ext4_li_info >li_request_list);
In my case mount takes 40minutes on server with 36 * 4Tb HDD.
Common user may face this in case of very slow dev ( /dev/mmcblkXXX)
Even more. If one of filesystems was frozen lazyinit_thread will simply
block on sb_start_write() so other mount/umount will be stuck forever.
This patch changes logic like follows:
- grab ->s_umount read sem before processing new li_request.
After that it is safe to drop li_list_mtx because all callers of
li_remove_request are holding ->s_umount for write.
- li_thread skips frozen SB's
Locking order:
Mh KOrder is asserted by umount path like follows: s_umount ->li_list_mtx so
the only way to to grab ->s_mount inside li_thread is via down_read_trylock
xfstests:ext4/023
#PSBM-49658
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Joe Maples <joe@frap129.org>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
