On Tue, Sep 08, 2020 at 04:15:26PM +0100, Christoph Hellwig wrote: > On Mon, Sep 07, 2020 at 10:52:35AM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > If the filesystem supports sparse inodes, we detect that an entire > > cluster buffer has no detectable inodes at all, and we can easily mark > > that part of the inode chunk sparse, just drop the cluster buffer and > > forget about it. This makes repair less likely to go to great lengths > > to try to save something that's totally unsalvageable. > > > > This manifested in recs[2].free=zeroes in xfs/364, wherein the root > > directory claimed to own block X and the inobt also claimed that X was > > inodes; repair tried to create rmaps for both owners, and then the whole > > mess blew up because the rmap code aborts on those kinds of anomalies. > > How is the rmap.c chunk related to this? The dino_chunks.c part looks > fine, and the rmap.c at least not bad, but I don't understand how it > fits here. I think that's a stray paste error; the chunk can be dropped. --D
