* [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb @ 2023-05-23 6:25 Wu Guanghao 2023-05-23 16:22 ` Darrick J. Wong 2023-05-24 1:36 ` Dave Chinner 0 siblings, 2 replies; 4+ messages in thread From: Wu Guanghao @ 2023-05-23 6:25 UTC (permalink / raw) To: Dave Chinner, Darrick J. Wong Cc: linux-xfs, liuzhiqiang (I), yangerkun, yi.zhang, chengzhihao1 After testing xfs_growfs + fsstress + fault injection, the following stack appeared when mounting the filesystem: [ 149.902032] XFS (loop0): xfs_buf_map_verify: daddr 0x200001 out of range, EOFS 0x200000 [ 149.902072] WARNING: CPU: 12 PID: 3045 at fs/xfs/xfs_buf.c:535 xfs_buf_get_map+0x5ae/0x650 [xfs] ... [ 149.902473] xfs_buf_read_map+0x59/0x330 [xfs] [ 149.902621] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] [ 149.902809] xlog_recover_buf_commit_pass2+0xff/0x640 [xfs] [ 149.902959] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] [ 149.903104] xlog_recover_items_pass2+0x55/0xd0 [xfs] [ 149.903247] xlog_recover_commit_trans+0x2e0/0x330 [xfs] [ 149.903390] xlog_recovery_process_trans+0x8e/0xf0 [xfs] [ 149.903531] xlog_recover_process_data+0x9c/0x130 [xfs] [ 149.903687] xlog_do_recovery_pass+0x3cc/0x5d0 [xfs] [ 149.903843] xlog_do_log_recovery+0x5c/0x80 [xfs] [ 149.903984] xlog_do_recover+0x33/0x1c0 [xfs] [ 149.904125] xlog_recover+0xdd/0x190 [xfs] [ 149.904265] xfs_log_mount+0x125/0x2f0 [xfs] [ 149.904410] xfs_mountfs+0x41a/0x910 [xfs] [ 149.904558] ? __pfx_xfs_fstrm_free_func+0x10/0x10 [xfs] [ 149.904725] xfs_fs_fill_super+0x4b7/0x940 [xfs] [ 149.904873] ? __pfx_xfs_fs_fill_super+0x10/0x10 [xfs] [ 149.905016] get_tree_bdev+0x19a/0x280 [ 149.905020] vfs_get_tree+0x29/0xd0 [ 149.905023] path_mount+0x69e/0x9b0 [ 149.905026] do_mount+0x7d/0xa0 [ 149.905029] __x64_sys_mount+0xdc/0x100 [ 149.905032] do_syscall_64+0x3e/0x90 [ 149.905035] entry_SYSCALL_64_after_hwframe+0x72/0xdc The trigger process is as follows: 1. Growfs size from 0x200000 to 0x300000 2. Using the space range of 0x200000~0x300000 3. The above operations have only been written to the log area on disk 4. Fault injection and shutdown filesystem 5. Mount the filesystem and replay the log about growfs, but only modify the superblock buffer without modifying the mp->m_sb structure in memory 6. Continuing the log replay, at this point we are replaying operation 2, then it was discovered that the blocks used more than mp->m_sb.sb_dblocks Therefore, during log replay, if there are any modifications made to the superblock, we should refresh the information recorded in the mp->m_sb. Signed-off-by: Wu Guanghao <wuguanghao3@huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index 43167f543afc..2ac3d2083188 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -22,6 +22,8 @@ #include "xfs_inode.h" #include "xfs_dir2.h" #include "xfs_quota.h" +#include "xfs_sb.h" +#include "xfs_ag.h" /* * This is the number of entries in the l_buf_cancel_table used during @@ -969,6 +971,29 @@ xlog_recover_buf_commit_pass2( goto out_release; } else { xlog_recover_do_reg_buffer(mp, item, bp, buf_f, current_lsn); + /* + * If the superblock buffer is modified, we also need to modify the + * content of the mp. + */ + if (bp->b_maps[0].bm_bn == XFS_SB_DADDR && bp->b_ops) { + struct xfs_dsb *sb = bp->b_addr; + + bp->b_ops->verify_write(bp); + error = bp->b_error; + if (error) + goto out_release; + + if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { + error = xfs_initialize_perag(mp, + be32_to_cpu(sb->sb_agcount), + be64_to_cpu(sb->sb_dblocks), + &mp->m_maxagi); + if (error) + goto out_release; + } + + xfs_sb_from_disk(&mp->m_sb, sb); + } } /* -- 2.27.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb 2023-05-23 6:25 [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb Wu Guanghao @ 2023-05-23 16:22 ` Darrick J. Wong 2023-05-24 2:38 ` Wu Guanghao 2023-05-24 1:36 ` Dave Chinner 1 sibling, 1 reply; 4+ messages in thread From: Darrick J. Wong @ 2023-05-23 16:22 UTC (permalink / raw) To: Wu Guanghao Cc: Dave Chinner, linux-xfs, liuzhiqiang (I), yangerkun, yi.zhang, chengzhihao1 On Tue, May 23, 2023 at 02:25:54PM +0800, Wu Guanghao wrote: > After testing xfs_growfs + fsstress + fault injection, the following stack appeared > when mounting the filesystem: > > [ 149.902032] XFS (loop0): xfs_buf_map_verify: daddr 0x200001 out of range, EOFS 0x200000 > [ 149.902072] WARNING: CPU: 12 PID: 3045 at fs/xfs/xfs_buf.c:535 xfs_buf_get_map+0x5ae/0x650 [xfs] > ... > [ 149.902473] xfs_buf_read_map+0x59/0x330 [xfs] > [ 149.902621] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.902809] xlog_recover_buf_commit_pass2+0xff/0x640 [xfs] > [ 149.902959] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.903104] xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.903247] xlog_recover_commit_trans+0x2e0/0x330 [xfs] > [ 149.903390] xlog_recovery_process_trans+0x8e/0xf0 [xfs] > [ 149.903531] xlog_recover_process_data+0x9c/0x130 [xfs] > [ 149.903687] xlog_do_recovery_pass+0x3cc/0x5d0 [xfs] > [ 149.903843] xlog_do_log_recovery+0x5c/0x80 [xfs] > [ 149.903984] xlog_do_recover+0x33/0x1c0 [xfs] > [ 149.904125] xlog_recover+0xdd/0x190 [xfs] > [ 149.904265] xfs_log_mount+0x125/0x2f0 [xfs] > [ 149.904410] xfs_mountfs+0x41a/0x910 [xfs] > [ 149.904558] ? __pfx_xfs_fstrm_free_func+0x10/0x10 [xfs] > [ 149.904725] xfs_fs_fill_super+0x4b7/0x940 [xfs] > [ 149.904873] ? __pfx_xfs_fs_fill_super+0x10/0x10 [xfs] > [ 149.905016] get_tree_bdev+0x19a/0x280 > [ 149.905020] vfs_get_tree+0x29/0xd0 > [ 149.905023] path_mount+0x69e/0x9b0 > [ 149.905026] do_mount+0x7d/0xa0 > [ 149.905029] __x64_sys_mount+0xdc/0x100 > [ 149.905032] do_syscall_64+0x3e/0x90 > [ 149.905035] entry_SYSCALL_64_after_hwframe+0x72/0xdc > > The trigger process is as follows: > > 1. Growfs size from 0x200000 to 0x300000 > 2. Using the space range of 0x200000~0x300000 > 3. The above operations have only been written to the log area on disk > 4. Fault injection and shutdown filesystem > 5. Mount the filesystem and replay the log about growfs, but only modify the > superblock buffer without modifying the mp->m_sb structure in memory > 6. Continuing the log replay, at this point we are replaying operation 2, then > it was discovered that the blocks used more than mp->m_sb.sb_dblocks > > Therefore, during log replay, if there are any modifications made to the > superblock, we should refresh the information recorded in the mp->m_sb. Heh, clever. Thanks for supplying a patch. :) > Signed-off-by: Wu Guanghao <wuguanghao3@huawei.com> > --- > fs/xfs/xfs_buf_item_recover.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c > index 43167f543afc..2ac3d2083188 100644 > --- a/fs/xfs/xfs_buf_item_recover.c > +++ b/fs/xfs/xfs_buf_item_recover.c > @@ -22,6 +22,8 @@ > #include "xfs_inode.h" > #include "xfs_dir2.h" > #include "xfs_quota.h" > +#include "xfs_sb.h" > +#include "xfs_ag.h" > > /* > * This is the number of entries in the l_buf_cancel_table used during > @@ -969,6 +971,29 @@ xlog_recover_buf_commit_pass2( > goto out_release; > } else { > xlog_recover_do_reg_buffer(mp, item, bp, buf_f, current_lsn); > + /* > + * If the superblock buffer is modified, we also need to modify the > + * content of the mp. > + */ > + if (bp->b_maps[0].bm_bn == XFS_SB_DADDR && bp->b_ops) { > + struct xfs_dsb *sb = bp->b_addr; I think the body of this if statement ought to be a separate function, e.g. STATIC int xlog_recover_sb_buffer(...) { struct xfs_dsb *sb = bp->b_addr; bp->b_ops->verify_write(bp); ... } Also, I think the callsite is better placed at the end of xlog_recover_do_reg_buffer. > + > + bp->b_ops->verify_write(bp); I was about to ask why you ran the full write verifier here instead of calling ->verify_struct (which skips the crc computation), but then I realized: const struct xfs_buf_ops xfs_sb_buf_ops = { .name = "xfs_sb", .magic = { cpu_to_be32(XFS_SB_MAGIC), cpu_to_be32(XFS_SB_MAGIC) }, .verify_read = xfs_sb_read_verify, .verify_write = xfs_sb_write_verify, }; So, heh. No structure verifier. I think for completeness xfs_sb_buf_ops ought to have one, but I'm willing to live with this for now. > + error = bp->b_error; > + if (error) > + goto out_release; > + > + if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { > + error = xfs_initialize_perag(mp, > + be32_to_cpu(sb->sb_agcount), > + be64_to_cpu(sb->sb_dblocks), > + &mp->m_maxagi); > + if (error) > + goto out_release; Might want to log a message here that the perag init is what killed log recovery. Other than those reorganization suggestions, I think this looks correct. Would you mind submitting your testcase to fstests? --D > + } > + > + xfs_sb_from_disk(&mp->m_sb, sb); > + } > } > > /* > -- > 2.27.0 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb 2023-05-23 16:22 ` Darrick J. Wong @ 2023-05-24 2:38 ` Wu Guanghao 0 siblings, 0 replies; 4+ messages in thread From: Wu Guanghao @ 2023-05-24 2:38 UTC (permalink / raw) To: Darrick J. Wong Cc: Dave Chinner, linux-xfs, liuzhiqiang (I), yangerkun, yi.zhang, chengzhihao1 在 2023/5/24 0:22, Darrick J. Wong 写道: > On Tue, May 23, 2023 at 02:25:54PM +0800, Wu Guanghao wrote: >> After testing xfs_growfs + fsstress + fault injection, the following stack appeared >> when mounting the filesystem: >> >> [ 149.902032] XFS (loop0): xfs_buf_map_verify: daddr 0x200001 out of range, EOFS 0x200000 >> [ 149.902072] WARNING: CPU: 12 PID: 3045 at fs/xfs/xfs_buf.c:535 xfs_buf_get_map+0x5ae/0x650 [xfs] >> ... >> [ 149.902473] xfs_buf_read_map+0x59/0x330 [xfs] >> [ 149.902621] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] >> [ 149.902809] xlog_recover_buf_commit_pass2+0xff/0x640 [xfs] >> [ 149.902959] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] >> [ 149.903104] xlog_recover_items_pass2+0x55/0xd0 [xfs] >> [ 149.903247] xlog_recover_commit_trans+0x2e0/0x330 [xfs] >> [ 149.903390] xlog_recovery_process_trans+0x8e/0xf0 [xfs] >> [ 149.903531] xlog_recover_process_data+0x9c/0x130 [xfs] >> [ 149.903687] xlog_do_recovery_pass+0x3cc/0x5d0 [xfs] >> [ 149.903843] xlog_do_log_recovery+0x5c/0x80 [xfs] >> [ 149.903984] xlog_do_recover+0x33/0x1c0 [xfs] >> [ 149.904125] xlog_recover+0xdd/0x190 [xfs] >> [ 149.904265] xfs_log_mount+0x125/0x2f0 [xfs] >> [ 149.904410] xfs_mountfs+0x41a/0x910 [xfs] >> [ 149.904558] ? __pfx_xfs_fstrm_free_func+0x10/0x10 [xfs] >> [ 149.904725] xfs_fs_fill_super+0x4b7/0x940 [xfs] >> [ 149.904873] ? __pfx_xfs_fs_fill_super+0x10/0x10 [xfs] >> [ 149.905016] get_tree_bdev+0x19a/0x280 >> [ 149.905020] vfs_get_tree+0x29/0xd0 >> [ 149.905023] path_mount+0x69e/0x9b0 >> [ 149.905026] do_mount+0x7d/0xa0 >> [ 149.905029] __x64_sys_mount+0xdc/0x100 >> [ 149.905032] do_syscall_64+0x3e/0x90 >> [ 149.905035] entry_SYSCALL_64_after_hwframe+0x72/0xdc >> >> The trigger process is as follows: >> >> 1. Growfs size from 0x200000 to 0x300000 >> 2. Using the space range of 0x200000~0x300000 >> 3. The above operations have only been written to the log area on disk >> 4. Fault injection and shutdown filesystem >> 5. Mount the filesystem and replay the log about growfs, but only modify the >> superblock buffer without modifying the mp->m_sb structure in memory >> 6. Continuing the log replay, at this point we are replaying operation 2, then >> it was discovered that the blocks used more than mp->m_sb.sb_dblocks >> >> Therefore, during log replay, if there are any modifications made to the >> superblock, we should refresh the information recorded in the mp->m_sb. > > Heh, clever. Thanks for supplying a patch. :) > >> Signed-off-by: Wu Guanghao <wuguanghao3@huawei.com> >> --- >> fs/xfs/xfs_buf_item_recover.c | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c >> index 43167f543afc..2ac3d2083188 100644 >> --- a/fs/xfs/xfs_buf_item_recover.c >> +++ b/fs/xfs/xfs_buf_item_recover.c >> @@ -22,6 +22,8 @@ >> #include "xfs_inode.h" >> #include "xfs_dir2.h" >> #include "xfs_quota.h" >> +#include "xfs_sb.h" >> +#include "xfs_ag.h" >> >> /* >> * This is the number of entries in the l_buf_cancel_table used during >> @@ -969,6 +971,29 @@ xlog_recover_buf_commit_pass2( >> goto out_release; >> } else { >> xlog_recover_do_reg_buffer(mp, item, bp, buf_f, current_lsn); >> + /* >> + * If the superblock buffer is modified, we also need to modify the >> + * content of the mp. >> + */ >> + if (bp->b_maps[0].bm_bn == XFS_SB_DADDR && bp->b_ops) { >> + struct xfs_dsb *sb = bp->b_addr; > > I think the body of this if statement ought to be a separate function, > e.g. > > STATIC int > xlog_recover_sb_buffer(...) > { > struct xfs_dsb *sb = bp->b_addr; > > bp->b_ops->verify_write(bp); > ... > } > > Also, I think the callsite is better placed at the end of > xlog_recover_do_reg_buffer. > >> + >> + bp->b_ops->verify_write(bp); > > I was about to ask why you ran the full write verifier here instead of > calling ->verify_struct (which skips the crc computation), but then I > realized: > > const struct xfs_buf_ops xfs_sb_buf_ops = { > .name = "xfs_sb", > .magic = { cpu_to_be32(XFS_SB_MAGIC), cpu_to_be32(XFS_SB_MAGIC) }, > .verify_read = xfs_sb_read_verify, > .verify_write = xfs_sb_write_verify, > }; > > So, heh. No structure verifier. I think for completeness > xfs_sb_buf_ops ought to have one, but I'm willing to live with this for > now. > >> + error = bp->b_error; >> + if (error) >> + goto out_release; >> + >> + if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { >> + error = xfs_initialize_perag(mp, >> + be32_to_cpu(sb->sb_agcount), >> + be64_to_cpu(sb->sb_dblocks), >> + &mp->m_maxagi); >> + if (error) >> + goto out_release; > > Might want to log a message here that the perag init is what killed log > recovery. > > Other than those reorganization suggestions, I think this looks correct. > Would you mind submitting your testcase to fstests? > > --D Thank you for your suggestion. I will make the changes in the v2 version. And we will try to submit test cases in the future. Thanks, Guanghao > >> + } >> + >> + xfs_sb_from_disk(&mp->m_sb, sb); >> + } >> } >> >> /* >> -- >> 2.27.0 > . > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb 2023-05-23 6:25 [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb Wu Guanghao 2023-05-23 16:22 ` Darrick J. Wong @ 2023-05-24 1:36 ` Dave Chinner 1 sibling, 0 replies; 4+ messages in thread From: Dave Chinner @ 2023-05-24 1:36 UTC (permalink / raw) To: Wu Guanghao Cc: Darrick J. Wong, linux-xfs, liuzhiqiang (I), yangerkun, yi.zhang, chengzhihao1 On Tue, May 23, 2023 at 02:25:54PM +0800, Wu Guanghao wrote: > After testing xfs_growfs + fsstress + fault injection, the following stack appeared > when mounting the filesystem: > > [ 149.902032] XFS (loop0): xfs_buf_map_verify: daddr 0x200001 out of range, EOFS 0x200000 > [ 149.902072] WARNING: CPU: 12 PID: 3045 at fs/xfs/xfs_buf.c:535 xfs_buf_get_map+0x5ae/0x650 [xfs] > ... > [ 149.902473] xfs_buf_read_map+0x59/0x330 [xfs] > [ 149.902621] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.902809] xlog_recover_buf_commit_pass2+0xff/0x640 [xfs] > [ 149.902959] ? xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.903104] xlog_recover_items_pass2+0x55/0xd0 [xfs] > [ 149.903247] xlog_recover_commit_trans+0x2e0/0x330 [xfs] > [ 149.903390] xlog_recovery_process_trans+0x8e/0xf0 [xfs] > [ 149.903531] xlog_recover_process_data+0x9c/0x130 [xfs] > [ 149.903687] xlog_do_recovery_pass+0x3cc/0x5d0 [xfs] > [ 149.903843] xlog_do_log_recovery+0x5c/0x80 [xfs] > [ 149.903984] xlog_do_recover+0x33/0x1c0 [xfs] > [ 149.904125] xlog_recover+0xdd/0x190 [xfs] > [ 149.904265] xfs_log_mount+0x125/0x2f0 [xfs] > [ 149.904410] xfs_mountfs+0x41a/0x910 [xfs] > [ 149.904558] ? __pfx_xfs_fstrm_free_func+0x10/0x10 [xfs] > [ 149.904725] xfs_fs_fill_super+0x4b7/0x940 [xfs] > [ 149.904873] ? __pfx_xfs_fs_fill_super+0x10/0x10 [xfs] > [ 149.905016] get_tree_bdev+0x19a/0x280 > [ 149.905020] vfs_get_tree+0x29/0xd0 > [ 149.905023] path_mount+0x69e/0x9b0 > [ 149.905026] do_mount+0x7d/0xa0 > [ 149.905029] __x64_sys_mount+0xdc/0x100 > [ 149.905032] do_syscall_64+0x3e/0x90 > [ 149.905035] entry_SYSCALL_64_after_hwframe+0x72/0xdc > > The trigger process is as follows: > > 1. Growfs size from 0x200000 to 0x300000 > 2. Using the space range of 0x200000~0x300000 > 3. The above operations have only been written to the log area on disk > 4. Fault injection and shutdown filesystem > 5. Mount the filesystem and replay the log about growfs, but only modify the > superblock buffer without modifying the mp->m_sb structure in memory > 6. Continuing the log replay, at this point we are replaying operation 2, then > it was discovered that the blocks used more than mp->m_sb.sb_dblocks > > Therefore, during log replay, if there are any modifications made to the > superblock, we should refresh the information recorded in the mp->m_sb. > > Signed-off-by: Wu Guanghao <wuguanghao3@huawei.com> There are a bunch of things we need to re-init post recovery if the superblock contents change during recovery. See xlog_do_recover() - if we are moving the sb log item recovery updates from post-recovery to "at log item recovery", then we need to be moving everything else in xlog_do_recover() here as well. That said.... > --- > fs/xfs/xfs_buf_item_recover.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c > index 43167f543afc..2ac3d2083188 100644 > --- a/fs/xfs/xfs_buf_item_recover.c > +++ b/fs/xfs/xfs_buf_item_recover.c > @@ -22,6 +22,8 @@ > #include "xfs_inode.h" > #include "xfs_dir2.h" > #include "xfs_quota.h" > +#include "xfs_sb.h" > +#include "xfs_ag.h" > > /* > * This is the number of entries in the l_buf_cancel_table used during > @@ -969,6 +971,29 @@ xlog_recover_buf_commit_pass2( > goto out_release; > } else { > xlog_recover_do_reg_buffer(mp, item, bp, buf_f, current_lsn); > + /* > + * If the superblock buffer is modified, we also need to modify the > + * content of the mp. > + */ > + if (bp->b_maps[0].bm_bn == XFS_SB_DADDR && bp->b_ops) { > + struct xfs_dsb *sb = bp->b_addr; > + > + bp->b_ops->verify_write(bp); > + error = bp->b_error; > + if (error) > + goto out_release; > + > + if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { > + error = xfs_initialize_perag(mp, > + be32_to_cpu(sb->sb_agcount), > + be64_to_cpu(sb->sb_dblocks), > + &mp->m_maxagi); > + if (error) > + goto out_release; > + } > + > + xfs_sb_from_disk(&mp->m_sb, sb); Ok, so what are we supposed to do here if the filesystem was shrunk? How do we guarantee that the mods that the shrink might do beyond the new end of device in the same checkpoint have already been replayed by the time the superblock change of size is replayed here? What if feature bits in the superblock were changed? e.g. we add a feature bit the filesystem doesn't understand? Or we have items for recovery in this checkpoint that are in the log after the superblock that depend on that feature bit not yet having been changed? What if the superblock got re-logged and the feature bit change subsequent objects rely on so gets moved to later in the checkpoint? i.e. there appears to be some important item recovery ordering issues we likely need to address here before we move the in-memory state updates from post-recovery to mid-recovery. I suspect that fixing this problem so that superblock updates also guarantee log recovery ordering is also going to need changing how we update feature and geometry state in the superblock.... -Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-05-24 2:39 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-05-23 6:25 [PATCH] xfs: fix the problem of mount failure caused by not refreshing mp->m_sb Wu Guanghao 2023-05-23 16:22 ` Darrick J. Wong 2023-05-24 2:38 ` Wu Guanghao 2023-05-24 1:36 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox