Re: [PATCH v9 00/14] io-uring/xfs: support async buffered writes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 22, 2022 at 04:27:07PM -0600, Jens Axboe wrote:
> On Thu, 16 Jun 2022 14:22:07 -0700, Stefan Roesch wrote:
> > This patch series adds support for async buffered writes when using both
> > xfs and io-uring. Currently io-uring only supports buffered writes in the
> > slow path, by processing them in the io workers. With this patch series it is
> > now possible to support buffered writes in the fast path. To be able to use
> > the fast path the required pages must be in the page cache, the required locks
> > in xfs can be granted immediately and no additional blocks need to be read
> > form disk.
> > 
> > [...]
> 
> Applied, thanks!
> 
> [01/14] mm: Move starting of background writeback into the main balancing loop
>         commit: 29c36351d61fd08a2ed50a8028a7f752401dc88a
> [02/14] mm: Move updates of dirty_exceeded into one place
>         commit: a3fa4409eec3c094ad632ac1029094e061daf152
> [03/14] mm: Add balance_dirty_pages_ratelimited_flags() function
>         commit: 407619d2cef3b4d74565999a255a17cf5d559fa4
> [04/14] iomap: Add flags parameter to iomap_page_create()
>         commit: 49b5cd0830c1e9aa0f9a3717ac11a74ef23b9d4e
> [05/14] iomap: Add async buffered write support
>         commit: ccb885b4392143cea1bdbd8a0f35f0e6d909b114
> [06/14] iomap: Return -EAGAIN from iomap_write_iter()
>         commit: f0f9828d64393ea2ce87bd97f033051c8d7a337f

I'm not sure /what/ happened here, but I never received the full V9
series, and neither did lore:

https://lore.kernel.org/linux-fsdevel/165593682792.161026.12974983413174964699.b4-ty@xxxxxxxxx/T/#t

As it is, I already have my hands full trying to figure out why
generic/522 reports file corruption after 20 minutes of running on
vanilla 5.19-rc3, so I don't think I'm going to get to this for a while
either.

The v8 series looked all right to me, but ********* I hate how our
development process relies on such unreliable **** tooling.  I don't
think it's a /great/ idea to be pushing new code into -next when both
the xfs and pagecache maintainers are too busy to read the whole thing
through... but did hch actually RVB the whole thing prior to v9?

--D

> [07/14] fs: Add check for async buffered writes to generic_write_checks
>         commit: cba06e23bc664ef419d389f1ed4cee523f468f8f
> [08/14] fs: add __remove_file_privs() with flags parameter
>         commit: 79d8ac83d6305fd8e996f720f955191e0d8c63b9
> [09/14] fs: Split off inode_needs_update_time and __file_update_time
>         commit: 1899b196859bac61ad71c3b3916e06de4b65246c
> [10/14] fs: Add async write file modification handling.
>         commit: 4705f225a56f216a59e09f7c2df16daabb7b4f76
> [11/14] io_uring: Add support for async buffered writes
>         commit: 6c8bbd82a43a0c7937e3e8e38cf46fcd90e15e68
> [12/14] io_uring: Add tracepoint for short writes
>         commit: 6c33dae4526ad079af6432aaf76827d0a27a9690
> [13/14] xfs: Specify lockmode when calling xfs_ilock_for_iomap()
>         commit: ddda2d473df70607bb456c515d984d05bf689790
> [14/14] xfs: Add async buffered write support
>         commit: e9cfc64a27f7a581b8c5d14da4efccfeae9c63bd
> 
> Best regards,
> -- 
> Jens Axboe
> 
> 



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux