On Mon, Jul 05, 2021 at 05:51:22PM +0200, Andreas Gruenbacher wrote:
> On Wed, Jun 30, 2021 at 2:29 PM Andreas Gruenbacher
> wrote:
> > Darrick,
> >
> > will you pick up those two patches and push them to Linus? They both
> > seem pretty safe.
>
> Hello, is there anybody out there?
>
> I've
On Wed, Jun 30, 2021 at 2:29 PM Andreas Gruenbacher wrote:
> Darrick,
>
> will you pick up those two patches and push them to Linus? They both
> seem pretty safe.
Hello, is there anybody out there?
I've put the two patches here with the sign-offs they've received:
On Wed, Jun 30, 2021 at 4:09 PM Matthew Wilcox wrote:
> On Tue, Jun 29, 2021 at 11:12:39AM +0200, Andreas Gruenbacher wrote:
> > Below is a version of your patch on top of v5.13 which has passed some
> > local testing here.
> >
> > Thanks,
> > Andreas
> >
> > --
> >
> > iomap: Permit pages
On Tue, Jun 29, 2021 at 11:12:39AM +0200, Andreas Gruenbacher wrote:
> Below is a version of your patch on top of v5.13 which has passed some
> local testing here.
>
> Thanks,
> Andreas
>
> --
>
> iomap: Permit pages without an iop to enter writeback
>
> Permit pages without an iop to enter
Darrick,
On Tue, Jun 29, 2021 at 7:47 AM Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 10:59:55PM +0100, Matthew Wilcox wrote:
> > > > so permit pages without an iop to enter writeback and create an iop
> > > > *then*. Would that solve your problem?
> > >
> > > It is the right thing to do,
Below is a version of your patch on top of v5.13 which has passed some
local testing here.
Thanks,
Andreas
--
iomap: Permit pages without an iop to enter writeback
Permit pages without an iop to enter writeback and create an iop *then*. This
allows filesystems to mark pages dirty without
On Mon, Jun 28, 2021 at 10:59:55PM +0100, Matthew Wilcox wrote:
> > > so permit pages without an iop to enter writeback and create an iop
> > > *then*. Would that solve your problem?
> >
> > It is the right thing to do, especially when combined with a feature
> > patch to not bother to create
On Tue, Jun 29, 2021 at 06:29:48AM +0100, Christoph Hellwig wrote:
> Hmm. Actually ->page_mkwrite is always is always called on an uptodate
> page and we even assert that. I should have remembered the whole page
> fault path better.
>
> So yeah, I think we should take patch 1 from Andreas, then
On Mon, Jun 28, 2021 at 06:47:58PM +0100, Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 06:39:09PM +0100, Matthew Wilcox wrote:
> > Not hugely happy with either of these options, tbh. I'd rather we apply
> > a patch akin to this one (plucked from the folio tree), so won't apply:
>
> > so
On Mon, Jun 28, 2021 at 8:07 PM Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 06:39:09PM +0100, Matthew Wilcox wrote:
> > Not hugely happy with either of these options, tbh. I'd rather we apply
> > a patch akin to this one (plucked from the folio tree), so won't apply:
>
> > so permit pages
On Mon, Jun 28, 2021 at 06:39:09PM +0100, Matthew Wilcox wrote:
> Not hugely happy with either of these options, tbh. I'd rather we apply
> a patch akin to this one (plucked from the folio tree), so won't apply:
> so permit pages without an iop to enter writeback and create an iop
> *then*.
On Mon, Jun 28, 2021 at 07:27:25PM +0200, Andreas Gruenbacher wrote:
> (1) In iomap_readpage_actor, an iomap_page is attached to the page even
> for inline inodes. This is unnecessary because inline inodes don't need
> iomap_page objects. That alone wouldn't cause any real issues, but when
>
On Mon, Jun 28, 2021 at 7:40 PM Matthew Wilcox wrote:
> On Mon, Jun 28, 2021 at 07:27:25PM +0200, Andreas Gruenbacher wrote:
> > (1) In iomap_readpage_actor, an iomap_page is attached to the page even
> > for inline inodes. This is unnecessary because inline inodes don't need
> > iomap_page
Hi Christoph and all,
the recent gfs2 switch from buffer heads to iomap for managing the
block-to-page mappings in commit 2164f9b91869 ("gfs2: use iomap for
buffered I/O in ordered and writeback mode") broke filesystems with a
block size smaller than the page size. This haüüens when iomap_page
14 matches
Mail list logo
