On Fri, May 25, 2018 at 07:58:14PM +0200, Andreas Grünbacher wrote:
> > The right way to deal with that is to make
> > inline data an explicit iomap type (done in my next posting of the
> > buffer head removal series), and then have iomap_begin find the data,
> > kmap it and return it in the
2018-05-18 18:04 GMT+02:00 Christoph Hellwig :
> On Tue, May 15, 2018 at 10:16:52AM +0200, Andreas Gruenbacher wrote:
>> > Yes. And from a quick look we can easily handle "stuffed" aka inline
>> > data with the existing architecture. We just need a new IOMAP_INLINE
>> > flag for the
On Tue, May 15, 2018 at 10:16:52AM +0200, Andreas Gruenbacher wrote:
> > Yes. And from a quick look we can easily handle "stuffed" aka inline
> > data with the existing architecture. We just need a new IOMAP_INLINE
> > flag for the extent type. Details will need to be worked out how to
> > pass
On 15 May 2018 at 09:22, Christoph Hellwig wrote:
> On Tue, May 15, 2018 at 11:11:47AM +1000, Dave Chinner wrote:
>> I'm not sure adding a per-page filesystem callout abstraction is
>> what we want in the iomap code. The commit message does not explain
>> why gfs2 needs per-page
On Tue, May 15, 2018 at 11:11:47AM +1000, Dave Chinner wrote:
> I'm not sure adding a per-page filesystem callout abstraction is
> what we want in the iomap code. The commit message does not explain
> why gfs2 needs per-page callouts, nor why the per-page work cannot
> be done/avoided by running
On Mon, May 14, 2018 at 05:36:19PM +0200, Andreas Gruenbacher wrote:
> Add write_begin and write_end operations to struct iomap_ops to provide
> a way of overriding the default behavior of iomap_write_begin and
> iomap_write_end. This is needed for implementing data journaling: in
> the data
Add write_begin and write_end operations to struct iomap_ops to provide
a way of overriding the default behavior of iomap_write_begin and
iomap_write_end. This is needed for implementing data journaling: in
the data journaling case, pages are written into the journal before
being written back to