On Wed, Mar 24, 2021 at 07:20:42PM +0100, Christoph Hellwig wrote: > On Wed, Mar 24, 2021 at 11:17:59AM -0700, Darrick J. Wong wrote: > > On Wed, Mar 24, 2021 at 03:21:16PM +0100, Christoph Hellwig wrote: > > > The legacy DMAPI fields were never set by upstream Linux XFS, and have no > > > way to be read using the kernel APIs. So instead of bloating the in-core > > > inode for them just copy them from the on-disk inode into the log when > > > logging the inode. The only caveat is that we need to make sure to zero > > > the fields for newly read or deleted inodes, which is solved using a new > > > flag in the inode. > > > > How long ago /did/ non-upstream XFS have DMAPI support? Does it still > > have it now? What's the cost of zeroing the fields? > > > > (Really what I'm saying is that I have so little clue of what dmevmask > > and dmstate do that I don't really know what Magic Smoke comes out if > > these fields get zeroed by an upstream kernel.) > > SuSE is shipping SGI patches for it in SLES12, their second newest > release. Which is still supported AFAIK. Indeed SLE12-SP3 was the last release to ship with DMAPI. The general support has ended (although LTSS is still supported till mid-2022). Either way booting/rescue from a non-SLE12 medium isn't supported, and this cleanup is not going to be backported (LTSS only receives critical fixes anyway), so it's probably safe to keep those fields always zeroed in upstream kernels. Perhaps even renaming those fields on xfs_dinode and xfs_log_dinode to unused/pads would make sense, since they could be repurposed. Needs though a couple of cleanups on the xfsprogs side too, so probably outside the scope of this series (I have a bunch of patches to that effect that I need to send sometime). Regards, Anthony
