[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZsXnFYIwww-Y6JH8@bfoster>
Date: Wed, 21 Aug 2024 09:09:41 -0400
From: Brian Foster <bfoster@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: Christian Brauner <brauner@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Chandan Babu R <chandan.babu@...cle.com>,
Jens Axboe <axboe@...nel.dk>, Jan Kara <jack@...e.cz>,
"Darrick J. Wong" <djwong@...nel.org>,
Theodore Ts'o <tytso@....edu>, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 6/6] xfs: refactor xfs_file_fallocate
On Wed, Aug 21, 2024 at 02:57:56PM +0200, Christoph Hellwig wrote:
> On Wed, Aug 21, 2024 at 08:44:31AM -0400, Brian Foster wrote:
> > > + error = xfs_reflink_unshare(XFS_I(inode), offset, len);
> > > + if (error)
> > > + return error;
> > > +
> >
> > Doesn't unshare imply alloc?
>
> Yes, ooks like that got lost and no test noticed it
>
> > > - if (xfs_file_sync_writes(file))
> > > + if (!error && xfs_file_sync_writes(file))
> > > error = xfs_log_force_inode(ip);
> >
> > I'd think if you hit -ENOSPC or something after doing a partial alloc to
> > a sync inode, you'd still want to flush the changes that were made..?
>
> Persistence behavior on error is always undefined. And that's also
> what the current code does, as it jumps past the log force from all
> error exits.
>
Ok, if this preserves existing behavior then I'm not too worried about
it. Thanks.
Brian
Powered by blists - more mailing lists