On 5:10 07/05, Christoph Hellwig wrote:
> On Thu, May 07, 2020 at 01:37:41PM +0200, David Sterba wrote:
> > On Wed, May 06, 2020 at 11:14:30PM -0700, Christoph Hellwig wrote:
> > > What is the status of this series? I haven't really seen it posted
> > > any time recently, and it would be sad to miss 5.8..
> >
> > I've been testing it and reporting to Goldwyn, but there are still
> > problems that don't seem to be fixable for 5.8 target.
>
> What are the issues, and how can we help to resolve them?
I investigated further and here are my findings.
geenric/475 fails because there are reservations left in the inode's
block reservations system which are not cleared out. So the system
triggers WARN_ON() while performing destroy_inode.
The problem is similar to described in:
50745b0a7f46 ("Btrfs: Direct I/O: Fix space accounting")
To test the theory, I framed an ugly patch of using an extra field
in current-> task_struct to store a number which carries the reservation
currently remaining like the patch does and it works. So what we need is
a way to carry reservation information from btrfs_direct_write() to
iomap's direct ops ->submit_io() where the reservations are consumed.
We cannot use a similar solution of using current->journal_info
because fdatawrite sequence in iomap_dio_rw() uses
current->journal_info.
We cannot perform data reservations and release in iomap_begin() and
iomap_end() for performance and accounting issues.
Ideas welcome.
--
Goldwyn
