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