On Fri, Sep 08, 2023 at 01:29:55AM +0100, Pavel Begunkov wrote:
> On 9/3/23 23:30, Dave Chinner wrote:
> > On Wed, Aug 30, 2023 at 02:11:31PM +0800, Hao Xu wrote:
> > > On 8/29/23 19:53, Matthew Wilcox wrote:
> > > > On Tue, Aug 29, 2023 at 03:46:13PM +0800, Hao Xu
On Sun, Aug 27, 2023 at 09:28:26PM +0800, Hao Xu wrote:
> From: Hao Xu
>
> Implement NOWAIT semantics for readdir. Return EAGAIN error to the
> caller if it would block, like failing to get locks, or going to
> do IO.
>
> Co-developed-by: Dave Chinner
Not really.
"C
e or nodiratime.
>
> Hi Matthew,
> The previous discussion shows this does cause issues in real
> producations:
> https://lore.kernel.org/io-uring/2785f009-2ebb-028d-8250-d5f3a3051...@gmail.com/#:~:text=fwiw%2C%20we%27ve%20just%20recently%20had%20similar%20problems%20with%20io_uring%20
r IO"
implementation we started with and don't try to solve every little
blocking problem that might exist in the VFS and filesystems...
-Dave
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
ms in the transaction
It's even worse than that - once we have committed intents, the
whole chain of intent processing must be run to completionr. Hence
we can't tolerate backing out of that defered processing chain half
way through because we might have to block.
Until we can roll back partial dirty transactions and partially
completed defered intent chains at any random point of completion,
XFS_TRANS_NOWAIT will not work.
-Dave.
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
shutdown as we cannot back out from failure
with dirty log items gracefully at this point.
-Dave.
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
tems at this point with shutting down the filesystem.
This points to XFS_TRANS_NOWAIT being completely broken, too,
because we don't call xfs_trans_set_sync() until just before we
commit the transaction. At this point, it is -too late- for
nowait+sync to be handled gracefully, and it will *always*
comes back to my first comments that XBF_TRYLOCK cannot simpy
be replaced with XBF_NOWAIT semantics...
-Dave.
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
5,7 @@ struct xfs_buf;
>
> /* flags used only as arguments to access routines */
> #define XBF_INCORE(1u << 29)/* lookup only, return if found in cache */
> -#define XBF_TRYLOCK (1u << 30)/* lock requested, but do not wait */
> +#define XBF_NOWAIT(1u << 30)/* mem/lock requested, but do not wait */
That's now a really poor comment. It doesn't describe the semantics
or constraints that NOWAIT might imply.
-Dave.
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
On Wed, May 19, 2021 at 11:00:03AM +0300, Avi Kivity wrote:
>
> On 18/05/2021 02.22, Dave Chinner wrote:
> >
> > > What I'd like to do is remove the fanout directories, so that for each
> > > logical
> > > "volume"[*] I have a single dir
single
threading modifications to your file index. You still need to use
fanout directories if you want concurrency during modification for
the cachefiles index, but that's a different design criteria
compared to directory capacity and modification/lookup scalability.
Cheers,
Dave.
--
Dave Chinne
gt; synchronous metadata changes being committed to the cache in one go
> (truncates, fallocates, fsync, xattrs, unlink+link of tmpfile) - and this
> can take quite a long time. The cache needs to be more proactive in
> getting stuff committed as it goes along.
Workqueues giv
ted to written until the
data is written back and the filesystem runs a conversion
transaction.
So, yeah, if you use FIEMAP to determine where data lies in a file
that is being actively modified, you're going get corrupt data
sooner rather than later. SEEK_HOLE/DATA are coherent with in
memory
lifts of the context setting up into
xfs_trans_alloc() back into the patchset before adding the
current->journal functionality patch.
Also, you need to test XFS code with CONFIG_XFS_DEBUG=y so that
asserts are actually built into the code and exercised, because this
ASSERT should have fired o
reservation recursion is used by XFS only, we can
> move the check into xfs_vm_writepage(s), per Dave.
>
> Cc: Darrick J. Wong
> Cc: Matthew Wilcox (Oracle)
> Cc: Christoph Hellwig
> Cc: Dave Chinner
> Cc: Michal Hocko
> Cc: David Howells
> Cc: Jeff Layton
> Sig
On Thu, Dec 17, 2020 at 03:06:27PM -0800, Darrick J. Wong wrote:
> On Fri, Dec 18, 2020 at 09:15:09AM +1100, Dave Chinner wrote:
> > The obvious solution: we've moved the saved process state to a
> > different context, so it is no longer needed for the current
> > t
if (tp->t_pflags)
memalloc_nofs_restore(tp->t_pflags);
}
and the problem is solved. The NOFS state will follow the active
transaction and not be reset until the entire transaction chain is
completed.
In the next patch you can go and introduce current->journal_info
into just the wrapper functions, maintaining the same overall
logic.
-Dave.
--
Dave Chinner
da...@fromorbit.com
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cachefs
n kswapd -- the only time we reach this code is when we're
> exiting and the task_struct is about to be destroyed anyway.
>
> Cc: Dave Chinner
> Acked-by: Michal Hocko
> Reviewed-by: Darrick J. Wong
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Matthew Wilcox (O
On Tue, Dec 15, 2020 at 08:42:08AM +0800, Yafang Shao wrote:
> On Tue, Dec 15, 2020 at 5:08 AM Dave Chinner wrote:
> > On Sun, Dec 13, 2020 at 05:09:02PM +0800, Yafang Shao wrote:
> > > On Thu, Dec 10, 2020 at 3:52 AM Darrick J. Wong
> > > wrote:
> > > > O
> > This patch is based on Darrick's work to fix the issue in xfs/141 in the
> > > earlier version. [1]
> > >
> > > 1. https://lore.kernel.org/linux-xfs/20201104001649.GN7123@magnolia
> > >
> > > Cc: Darrick J. Wong
>
trans_context_active
> To check whehter current is in fs transcation or not
> - xfs_trans_context_swap
> Transfer the transaction context when rolling a permanent transaction
>
> These two new helpers are instroduced in xfs_trans.h.
>
> Cc: Darrick J. Wong
> Cc: Matt
& (PF_MEMALLOC|PF_KSWAPD)) ==
> PF_MEMALLOC))
> goto redirty;
>
> [2]. https://lore.kernel.org/linux-xfs/20201104001649.GN7123@magnolia/
>
> Cc: Darrick J. Wong
> Cc: Matthew Wilcox (Oracle)
> Cc: Christoph Hellwig
> Cc: Dave Chinner
> Cc: M
saction context is a bug in XFS.
IOWs, we are waiting on a new version of this patchset to be posted:
https://lore.kernel.org/linux-xfs/20201103131754.94949-1-laoar.s...@gmail.com/
so that we can get rid of this from iomap and check the transaction
recursion case directly in the XFS code. Then your pr
23 matches
Mail list logo
