Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 23 Dec 2020 03:39:01 +0800
From:   Gao Xiang <hsiangkao@redhat.com>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Huang Jianan <huangjianan@oppo.com>, guoweichao@oppo.com,
        linux-erofs@lists.ozlabs.org, zhangshiming@oppo.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] erofs: support direct IO for uncompressed file
Message-ID: <20201222193901.GA1892159@xiangao.remote.csb>
References: <20201214140428.44944-1-huangjianan@oppo.com>
 <20201222142234.GB17056@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20201222142234.GB17056@infradead.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

Hi Christoph,

On Tue, Dec 22, 2020 at 02:22:34PM +0000, Christoph Hellwig wrote:
> Please do not add new callers of __blockdev_direct_IO and use the modern
> iomap variant instead.

We've talked about this topic before. The current status is that iomap
doesn't support tail-packing inline data yet (Chao once sent out a version),
and erofs only cares about read intrastructure for now (So we don't think
more about how to deal with tail-packing inline write path). Plus, the
original patch was once lack of inline data regression test from gfs2 folks.

The main use case I know so far is to enable direct I/O and leave loop images
uncompressed for loop devices. And making the content of the loop images
compressed to avoid double caching.

Personally, I'd like to convert it to iomap infrastructure as well. So if it
has some concern for __blockdev_direct_IO as an interim solution, hope that
Jianan could pick this work up. That would be better.

Thanks,
Gao Xiang

>