On Mon, May 23, 2022 at 01:34:45PM +1000, Dave Chinner wrote: > On Sun, May 22, 2022 at 08:28:42AM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > libxfs itself should never be messing with whether or not to enable > > logging for extended attribute updates -- this decision should be made > > on a case-by-case basis by libxfs callers. Move the code that actually > > enables the log features to xfs_xattr.c, and adjust the callers. > > > > This removes an awkward coupling point between libxfs and what would be > > libxlog, if the XFS log were actually its own library. Furthermore, it > > makes bulk attribute updates and inode security initialization a tiny > > bit more efficient, since they now avoid cycling the log feature between > > every single xattr. > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > --- > > fs/xfs/libxfs/xfs_attr.c | 12 +------- > > fs/xfs/xfs_acl.c | 10 +++++++ > > fs/xfs/xfs_ioctl.c | 22 +++++++++++++--- > > fs/xfs/xfs_ioctl.h | 2 + > > fs/xfs/xfs_ioctl32.c | 4 ++- > > fs/xfs/xfs_iops.c | 25 ++++++++++++++---- > > fs/xfs/xfs_log.c | 45 -------------------------------- > > fs/xfs/xfs_log.h | 1 - > > fs/xfs/xfs_super.h | 2 + > > fs/xfs/xfs_xattr.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++ > > 10 files changed, 120 insertions(+), 68 deletions(-) > > This seems like the wrong way to approach this. I would have defined > a wrapper function for xfs_attr_set() to do the log state futzing, > not moved it all into callers that don't need (or want) to know > anything about how attrs are logged internally.... I started doing this, and within a few hours realized that I'd set upon yet *another* refactoring of xfs_attr_set. I'm not willing to do that so soon after Allison's refactoring, so I'm dropping this patch. --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
