Re: [PATCH 02/10] xfs: set lv_bytes in xlog_write_one_vec

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Nov 03, 2025 at 11:43:19AM +0100, Christoph Hellwig wrote:
> On Fri, Oct 31, 2025 at 05:04:09PM -0700, Darrick J. Wong wrote:
> > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
> > > index ed83a0e3578e..382c55f4d8d2 100644
> > > --- a/fs/xfs/xfs_log.c
> > > +++ b/fs/xfs/xfs_log.c
> > > @@ -858,14 +858,15 @@ xlog_write_one_vec(
> > >  	struct xfs_log_vec	lv = {
> > >  		.lv_niovecs	= 1,
> > >  		.lv_iovecp	= reg,
> > > +		.lv_bytes	= reg->i_len,
> > 
> > I'm surprised that nothing's noticed the zero lv_bytes, but I guess
> > unmount and commit record writes have always wanted a full write anyway?
> > 
> > Question: if lv_bytes is no longer zero, can this fall into the
> > xlog_write_partial branch?
> 
> The unmount format is smaller than an opheader, so we won't split it
> because of that, but unless I'm misreading things it could fix a bug
> where we'd not get a new iclog when needed for it otherwise?

Yeah, I think that's theoretically possible.  I wonder what that would
look like to generic/388 though?  I haven't seen any problems with log
recovery for a while other than the large xattr thing, so maybe it's not
worth worrying about.

> The commit record is just an an opheader without any payload, so there
> is no way to even split it in theory.

<nod>

--D