[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240828040633.GC30409@lst.de>
Date: Wed, 28 Aug 2024 06:06:33 +0200
From: Christoph Hellwig <hch@....de>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Christian Brauner <brauner@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Chandan Babu R <chandan.babu@...cle.com>,
Brian Foster <bfoster@...hat.com>, Jens Axboe <axboe@...nel.dk>,
Jan Kara <jack@...e.cz>, 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 4/6] xfs: call xfs_flush_unmap_range from
xfs_free_file_space
On Tue, Aug 27, 2024 at 09:03:23AM -0700, Darrick J. Wong wrote:
> On Tue, Aug 27, 2024 at 08:50:48AM +0200, Christoph Hellwig wrote:
> > Call xfs_flush_unmap_range from xfs_free_file_space so that
> > xfs_file_fallocate doesn't have to predict which mode will call it.
> >
> > Signed-off-by: Christoph Hellwig <hch@....de>
>
> Hmm. I /think/ it's ok to shift the xfs_flush_unmap_range after the
> file_modified and some of the other EINVAL bailouts that can happen
> before xfs_free_file_space gets called. Effectively that means that we
> can fail faster now? :)
Yes, failing faster has always been my personal benchmark :)
Powered by blists - more mailing lists