ext4: fix lazy initialization next schedule time computation in more granular unit
PATCH 1/1 ext4: fix lazy initialization next schedule time computation in more granular unit
commit 39fec6889d15a658c3a3ebb06fd69d3584ddffd3 upstream.
Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value.
---
Member lr_sbi was removed from the struct ext4_li_request since kernel 5.9 so the way to access s_li_wait_mult was also changed. To adapt to the old kernel versions, adjust the upstream fix by following the old ext4_li_request strucutre.
fs/ext4/super.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/ext4/super.c +4 -5
@@ -3071,8 +3071,8 @@ static int ext4_run_li_request(struct ext4_li_request *elr)struct ext4_group_desc *gdp =NULL ;ext4_group_t group, ngroups;struct super_block *sb; -unsigned long timeout =0 ;int ret =0 ; +u64 start_time; sb = elr->lr_super; ngroups =EXT4_SB (sb)->s_groups_count;
@@ -3092,13 +3092,12 @@ static int ext4_run_li_request(struct ext4_li_request *elr) ret =1 ;if (!ret) { - timeout = jiffies; + start_time =ktime_get_real_ns (); ret =ext4_init_inode_table (sb, group, elr->lr_timeout ?0 :1 );if (elr->lr_timeout ==0 ) { - timeout = (jiffies - timeout) * - elr->lr_sbi->s_li_wait_mult; - elr->lr_timeout = timeout; + elr->lr_timeout =nsecs_to_jiffies ((ktime_get_real_ns () - start_time) * + elr->lr_sbi->s_li_wait_mult); } elr->lr_next_sched = jiffies + elr->lr_timeout; elr->lr_next_group = group +1 ;
Signature · 1 line
2.16.6
Quoted 15 lines · Shaoying Xu
commit
39fec6889d15a658c3a3ebb06fd69d3584ddffd3upstream.Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value.
Fixes bfff68738f1c ("ext4: add support for lazy inode table initialization")Signed-off-by Shaoying Xu <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>
Quoted 5 lines
---
Memberlr_sbiwas removed from the structext4_li_requestsince kernel 5.9 so the way to accesss_li_wait_multwas also changed. To adapt to the old kernel versions, adjust the upstream fix by following the oldext4_li_requeststrucutre.
Now queued up, thanks.
greg k-h
Thank you! Can the patch also be added to kernel 4.19 and 4.14 please?
Quoted 29 lines · Greg KH
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Quoted 15 lines · Shaoying Xu
commit
39fec6889d15a658c3a3ebb06fd69d3584ddffd3upstream.Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value.
Fixes bfff68738f1c ("ext4: add support for lazy inode table initialization")Signed-off-by Shaoying Xu <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>Quoted 5 lines
---
Memberlr_sbiwas removed from the structext4_li_requestsince kernel 5.9 so the way to accesss_li_wait_multwas also changed. To adapt to the old kernel versions, adjust the upstream fix by following the oldext4_li_requeststrucutre.Now queued up, thanks.
greg k-h
Quoted 1 line · Shaoying Xu
Thank you! Can the patch also be added to kernel 4.19 and 4.14 please?
Now queued up, thanks.
greg k-h