On Sat, Nov 19, 2022 at 9:38 AM Ryusuke Konishi wrote: > On Tue, Nov 15, 2022 at 3:39 AM Ryusuke Konishi wrote: > > On Mon, Nov 14, 2022 at 12:39 PM Peng Zhang wrote: > What was happening here was complicated. > There were two state inconsistencies in DAT: > 1) A virtual block number (vblocknr == 6145) in the report, was used > twice in a btree. > Because of this, nilfs_dat_commit_end() on that address was called twice. > 2) For the virtual block number (vblocknr == 6145), the DAT bitmap > status was free (second anomaly), and nilfs_dat_commit_alloc() was > performed at the same time as the second nilfs_dat_commit_end() above. > > As I mentioned, when nilfs_dat_commit_end() frees a virtual block > number in the bitmap of DAT, nilfs_dat_prepare_end() usually allocates > buffer heads of the bitmap block and the descriptor block, and sets > them to the request struct. But, the above two anomalies overlap, as > you pointed out, de_block is initialized to 0 by > nilfs_dat_prepare_alloc() in the middle of "prepare" and "commit", and I wrote it wrong, this should be ".., de_blocknr is initialized to 0 by nilfs_dat_commit_alloc() ..". Ryusuke Konishi
