On Mon, May 16, 2022 at 09:47:05AM -0700, Stefan Roesch wrote:
> This change uses the new iomap_page_create_gfp() function in the
> function __iomap_write_begin().
>
> No intended functional changes in this patch.
But there is one. I don't know if it's harmful or not.
> const struct iomap *srcmap = iomap_iter_srcmap(iter);
> - struct iomap_page *iop = iomap_page_create(iter->inode, folio);
> + struct iomap_page *iop = to_iomap_page(folio);
> loff_t block_size = i_blocksize(iter->inode);
> loff_t block_start = round_down(pos, block_size);
> loff_t block_end = round_up(pos + len, block_size);
> + unsigned int nr_blocks = i_blocks_per_folio(iter->inode, folio);
> size_t from = offset_in_folio(folio, pos), to = from + len;
> size_t poff, plen;
> + gfp_t gfp = GFP_NOFS | __GFP_NOFAIL;
For the case where the folio is already uptodate, would need an iop to
be written back (ie nr_blocks > 1) but doesn't have an iop, we used to
create one here, and now we don't.
How much testing has this seen with blocksize < 4k?
> if (folio_test_uptodate(folio))
> return 0;
> folio_clear_error(folio);
>
> + if (!iop && nr_blocks > 1)
> + iop = iomap_page_create_gfp(iter->inode, folio, nr_blocks, gfp);
> +
> do {
> iomap_adjust_read_range(iter->inode, folio, &block_start,
> block_end - block_start, &poff, &plen);
> --
> 2.30.2
>
>
