On Wed, 29 May 2024, Trond Myklebust wrote:
> On Tue, 2024-05-28 at 11:19 +1000, NeilBrown wrote:
> > On Tue, 28 May 2024, Trond Myklebust wrote:
> > > On Mon, 2024-05-27 at 13:04 +1000, NeilBrown wrote:
> > > >
> > > > dentry->d_fsdata is
l to unblock_revalidate().
Reported-and-tested-by: Richard Kojedzinszky
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown
---
fs/nfs/dir.c | 47 +
On Tue, 28 May 2024, Trond Myklebust wrote:
> On Mon, 2024-05-27 at 13:04 +1000, NeilBrown wrote:
> >
> > dentry->d_fsdata is set to NFS_FSDATA_BLOCKED while unlinking or
> > renaming-over a file to ensure that no open succeeds while the NFS
> > oper
ests that arm64 does need barriers some
times.
I don't have arm64 hardware to test on but I'm happy with your
test results.
Thanks,
NeilBrown
>
> Regards,
> Richard
>
>
> On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown wrote:
>
> On Sun, 26 May 2024, Rich
l to unblock_revalidate().
Reported-and-tested-by: Richard Kojedzinszky
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown
---
fs/nfs/dir.c | 44 ++
ystem.
I've made some cosmetic improvements to the patch and will post it to
the NFS maintainers.
Thanks again,
NeilBrown
>
> Thanks,
> Richard
>
> 2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
> > Dear Neil,
> >
> > I've applied you
tructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.
Or you could try this patch. It might help, but I don't have high
hopes. It adds some memory barriers and fixes a bug which would cause a
problem if memory allocation failed (but memory
ponse,
and then fail the mount. That would happen if, for example, rpc.mountd
wasn't running.
So I think these failures are caused by some problem with restarting the
services and aren't actually testing the code at all.
Could you try again and make sure rpcbind and rpc.mountd are running on
the server before attempting the mount?
Thanks,
NeilBrown
or is it an "xor"?
>>>
>
> I think there are two questions:
>
> a) can they both exist in different packages that conflict with each
> other? I'm guessing that will probably be yes.
>
> b) can they both be installed simultaneously? Possibly not (can an
On Wed, 24 Jul 2013 04:02:15 +0100 Ben Hutchings wrote:
> Neil, does the report below sound like the bug you fixed with:
>
> commit 7bb23c4934059c64cbee2e41d5d24ce122285176
> Author: NeilBrown
> Date: Tue Jul 16 16:50:47 2013 +1000
>
> md/raid10: fix two proble
t; I've tested against the following versions: 3.8-rc5, 3.7.5, 3.4.28,
> 3.2.37, 3.0.61, 2.6.34.14 and 2.6.32.60.
>
> Cheers,
> Sebastian
Thanks!
I've added "Cc: sta...@vger.kernel.org" and will forward it to Linus shortly.
NeilBrown
signature.asc
Description: PGP signature
On Mon, 7 Jan 2013 13:34:05 +0100 (CET) bug556...@arcor.de wrote:
>
> Hello,
> thanks for responding.
>
> NeilBrown:
> > The upstream bug tracker is
> >mailto:linux-r...@vger.kernel.org
>
> Well ok, though a regular mailinglist makes it rather hard t
fixed by cleaning up the bio path so that big bios
are split by the device that needs the split, not be the fs sending the bio.
I would not be at all happy to have md do the extra buffering and splitting
that you suggest.
Maybe the best interim fix is to reject the added device is its limits are
too
mmand for 24 hours, instead of minutes
> > when running last kernel from Linus git tree, up to commit 9e85a6f.
> >
> > For more information follow the thread on linux-r...@vger.kernel.org:
> > http://marc.info/?l=linux-raid&m=134136614330049&w=4
>
> Follow
s is guaranteed always
to work. So it could be a significant performance hit for the common case.
We really need either:
- The fs sends down arbitrarily large requests, and the lower layers split
them up if/when needed
or
- A mechanism for a block device to tell the layer above that something h
15 matches
Mail list logo
