On Thu, Apr 10, 2025 at 08:27:49AM +0200, Christoph Hellwig wrote: > On Wed, Apr 09, 2025 at 09:10:12AM -0700, Darrick J. Wong wrote: > > On Wed, Apr 09, 2025 at 09:55:30AM +0200, Christoph Hellwig wrote: > > > Note really much to do here. Mostly ignore the validation and > > > regeneration of the bitmap and summary inodes. Eventually this > > > could grow a bit of validation of the hardware zone state. > > > > What do we actually do about the hardware zone state? If the write > > pointer is lower than wherever the rtrmapbt thinks it is, then we're > > screwed, right? > > Yes. See offlist discussion with Hans. To summarize -- in the ideal world we'd have another file mapping extent state for "damaged". Then we could amend the media error handler (aka the stuff in xfs_notify_failure.c) to set all the mappings to damaged and set an inode flag saying that the file lost data. Reads to the damaged areas would return EIO. We'd also be able to report to userspace exactly what was lost. Unfortunately we don't really have that, so all we can do with the current ondisk format is ... remove the mappings? > > Does it matter if the hw write pointer is higher than where the rtrmapbt > > thinks it is? In that case, a new write will be beyond the last write > > that the filesystem knows about, but the device will tell us the disk > > address so it's all good aside from the freertx counters being wrong. I > > think? > > Yes. That's actually a totally expected case for an unclean shutdown > with data I/O in flight. freertx is recalculate at each mount, and > the space not recorded in the rmapbt is simply marked as reclaimable > through garbage collection. <nod> Ok, that's what I thought was going on, thanks for the reminder. --D
