https://bugzilla.kernel.org/show_bug.cgi?id=214077 Gao Xiang (xiang@xxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xiang@xxxxxxxxxx --- Comment #5 from Gao Xiang (xiang@xxxxxxxxxx) --- Hi, I tried several times without any luck in my own VM, FSTYP -- xfs (debug) PLATFORM -- Linux/x86_64 AliYun 5.13.0-rc4+ #1 SMP Mon Aug 23 20:17:12 CST 2021 MKFS_OPTIONS -- -f -m crc=1,finobt=1,reflink=1,rmapbt=1,bigtime=1,inobtcount=1 -b size=1024 /dev/loop1 MOUNT_OPTIONS -- /dev/loop1 /fs/loop1 xfs/168 197s ... 225s Ran: xfs/168 Passed all 1 tests But with my own understanding, I guess that may be due to the following condition: /* * Roll the transaction before trying to re-init the per-ag * reservation. The new transaction is clean so it will cancel * without any side effects. */ error = xfs_defer_finish(tpp); <--- here we unlock the AGF, new allocation allowed. if (error) return error; error = -ENOSPC; goto resv_init_out; } xfs_ialloc_log_agi(*tpp, agibp, XFS_AGI_LENGTH); xfs_alloc_log_agf(*tpp, agfbp, XFS_AGF_LENGTH); return 0; resv_init_out: err2 = xfs_ag_resv_init(agibp->b_pag, *tpp); <--- so resv init can be failed here. if (!err2) return error; resv_err: xfs_warn(mp, "Error %d reserving per-AG metadata reserve pool.", err2); xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); return err2; As I mentioned before, I'm not sure if growfs has similiar race like this. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
