On 1/19/22 6:20 PM, Darrick J. Wong wrote:
From: Darrick J. Wong <djwong@xxxxxxxxxx>
Get rid of these flags and the m_flags field, since none of them do
anything anymore.
diff --git a/db/attrset.c b/db/attrset.c
index 98a08a49..6441809a 100644
--- a/db/attrset.c
+++ b/db/attrset.c
@@ -107,7 +107,6 @@ attr_set_f(
break;
case 'n':
- mp->m_flags |= LIBXFS_MOUNT_COMPAT_ATTR;
break;
That leaves an interesting no-op! I think IRC discussion ended at
"haha it was a no-op before, too!" but maybe a comment to note the
weird wart would be reasonable while we work out what to do with
it, since it's so blazingly obvious now.
/* value length */
@@ -169,7 +168,6 @@ attr_set_f(
set_cur_inode(iocur_top->ino);
out:
- mp->m_flags &= ~LIBXFS_MOUNT_COMPAT_ATTR;
if (args.dp)
libxfs_irele(args.dp);
if (args.value)
@@ -211,7 +209,6 @@ attr_remove_f(
break;
case 'n':
- mp->m_flags |= LIBXFS_MOUNT_COMPAT_ATTR;
break;
here as well
...
diff --git a/libxlog/xfs_log_recover.c b/libxlog/xfs_log_recover.c
index 592e4502..d43914b9 100644
--- a/libxlog/xfs_log_recover.c
+++ b/libxlog/xfs_log_recover.c
@@ -827,7 +827,6 @@ xlog_find_tail(
* superblock counters from the perag headers if we
* have a filesystem using non-persistent counters.
*/
- log->l_mp->m_flags |= XFS_MOUNT_WAS_CLEAN;
}
}
Preceeding comment should go too, then, or maybe we should leave the
equivalent opstate in place there? I'm not sure if the libxlog copies are
supposed to stay as true as possible to kernelspace, or if we expect them
to diverge and remove the pointless bits. Probably the latter, right?
So probably just nuke the comment.
-Eric
