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
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 Tue, Nov 22 2016, Andy Smith wrote:
> Hi Neil,
>
> On Tue, Nov 22, 2016 at 09:56:28AM +1100, NeilBrown wrote:
>> Thanks. Sorry this is taking a lot of back-and-forth...
>
> No worries. This is very interesting to me and I'd also like to know
> what is going wrong
e sense to round up to 4K sometimes, and use 512 at other
times. However the correct test isn't whether cluster-raid is in use.
The metadata has always been aligned on a 4K boundary.
If data_offset and bblog_offset and bitmap_offset all have 4K alignment,
then rounding up to 4K for the bitmap writes would be correct.
If anything have a smaller alignment, then it isn't necessary and so
should be avoided.
So the best fix would be to test those 3 offsets, and round up to a
multiple of 4096 only if all of them are on a 4K boundary.
NeilBrown
signature.asc
Description: PGP signature
you apply the above patch to mdadm (maybe get clean source with
git clone git://neil.brown.name/mdadm
then apply the patch and run "make") you should be able to assemble
--update=metadata and get a working array.
Thanks for the report.
NeilBrown
signature.asc
Description: PGP signature
#x27;t try to
debug booting degraded md with dracut without first updating at least
to verions 042 - and I notice there is 043 out, so best to start with
that.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
mdadm crashed - that code path should hardly ever be reached.
Anyway, the fix is at:
http://git.neil.brown.name/?p=mdadm.git;a=commitdiff;h=2609f339028a6035a3fadb1190b565438000e35c
in case the Debian maintainer wants to pick it up.
Thanks for the report.
NeilBrown
>
> I managed to
back into it.
It looks to me like you are trying to assemble an array which is not
currently active. So
mdadm --assemble /dev/md/storage /dev/sdg /dev/sdh /dev/sdi /dev/sdj
is probably the command that you want.
NeilBrown
pgpyK6yuGD0h5.pgp
Description: OpenPGP digital signature
dd" if you believe that path failure
is significantly more likely than media or mechanism failure.
i.e. the best choice depends on the particular hardware in use.
NeilBrown
>
>
> ## automatically use devices as new spares (enabling rebuild)
> #
> # POLICY domain=default acti
's 64 petabytes.
I decide to just do the simple transformation. If we get arrays close to
petabytes I would want to make other changes, like reporting the number of
terabytes for larger arrays.
Thanks,
NeilBrown
> >
> > The following patch uses a more complicated formula t
is not a "segfault", it is an uncaught interrupt.
There is no evidence that it is related to md except by pure co-incidence.
11: 60XT-PIC-XT-PICsata_via
Presumably problem is related to 'via' SATA driver.
NeilBrown
pgpJ6rbaBrIEj.pgp
Description: OpenPGP digital signature
h
commit f81a2b56c4b437f66aaf5582a9c6b7f5ab2103c4
Author: NeilBrown
Date: Tue Oct 22 09:55:04 2013 +1100
Assembe: fix bug in force_array - it wasn't forcing properly.
which is in mdadm-3.3.1.
NeilBrown
pgp7CNgR9NaGZ.pgp
Description: OpenPGP digital signature
... depending on the exact stripe size etc.
mke2fs has stride= and stripe_width= options to encourage it rotate the
bitmaps etc around the drives.
NeilBrown
signature.asc
Description: PGP signature
this. My guess is that it is caused by
the filesystem - which I see is ext4.
Maybe on first write, the filesystem loads some tables off disk, and all the
tables are on the first drive.
It would be worth asking on ext3-us...@redhat.com.au
http://www.redhat.com/mailman/listinfo/ext3-users
NeilBrown
signature.asc
Description: PGP signature
rpc1 recommends no packages.
> >
> > libtirpc1 suggests no packages.
> >
> > -- no debconf information
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755703
>
> How can I fix this bug in Debian?
Build both nfs-utils and libtirpc *without* --with-gssglue, get rid of
libgssglue1.
(this was a major headache for openSUSE, but some of that was internal issues)
NeilBrown
signature.asc
Description: PGP signature
On Mon, 6 Jan 2014 04:11:10 + Dimitri John Ledkov wrote:
> Control: tag -1 patch
>
>
> On 6 January 2014 03:28, NeilBrown wrote:
> >
> > On Wed, 1 Jan 2014 04:06:44 + Dimitri John Ledkov
> > wrote:
> >
> > > On 1 January 2014 03:55, Nei
remental check" script
then I think that is a great idea, but rather than treating it as a "Debian"
thing, post the proposal to linux-r...@vger.kernel.org and get feedback and
suggestions there and when it is ready we can include it in the upstream
mdadm package.
NeilBrown
>
> > I'll think about it all more.
>
> Any news?
signature.asc
Description: PGP signature
On Wed, 1 Jan 2014 04:06:44 + Dimitri John Ledkov wrote:
> On 1 January 2014 03:55, NeilBrown wrote:
> > On Wed, 01 Jan 2014 02:49:26 + Dimitri John Ledkov
> > wrote:
> >
> >> I'm also CC'ing upstream author of wiggle, to look into big-endian
has been released.
I would suggest trying v1.0 and see if the test failures are fixed there or
not.
I don't have access to a big-endian so I cannot easily perform the tests and
find the cause directly.
NeilBrown
signature.asc
Description: PGP signature
On Sat, 14 Dec 2013 16:38:08 + Ben Hutchings wrote:
> Right, I don't think it is correct to look for firmware RAID signatures
> inside partitions.
Upstream commit 357ac1067835d1cdd5f80acc28501db0ffc64957
NeilBrown
signature.asc
Description: PGP signature
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
On Mon, 08 Jul 2013 02:38:17 +0200 Christoph Anton Mitterer
wrote:
> On Mon, 2013-07-08 at 09:48 +1000, NeilBrown wrote:
> > Maturity.
> Ah... I wasn't aware that upstream still actively discourages it's
> use :)
I don't discourage it's use, but I don'
On Mon, 08 Jul 2013 01:30:51 +0200 Christoph Anton Mitterer
wrote:
> - raid6check + manpage
> very nice tool... why is it missing?
Maturity.
Default output is currently too verbose.
Currently report errors on a whole-chunk basis rather than a block-by-block
basis.
NeilBrown
signatu
On Mon, 6 May 2013 09:22:42 +0200 (CEST) Thorsten Glaser
wrote:
> On Wed, 1 May 2013, NeilBrown wrote:
>
> > "mdadm --examine --scan" looks at all devices, whether they are currently
> > attached to an md array or not. Maybe it found a device that looked like a
&
ow? It should list "dev=" for
each array.
Also you might be wanting 'mdadm --detail --scan' if you already have the
arrays assembled.
NeilBrown
signature.asc
Description: PGP signature
, info = 0x6ad7f0,
> > ignore_hw_compat = 0, updates = 0x0, update_tail = 0x0, arrays = 0x0,
> > sock = 0, devnum = 3, devname = 0x0,
> > devcnt = 0, retry_soon = 0, devs = 0x0}
> > (gdb) p st->info
> > $5 = (void *) 0x6ad7f0
> > (gdb) p *(struct devinfo *)(st->info)
> > $6 = {fd = -1, devname = 0x7fffec02 "/dev/sdb1", disk = {number = 2,
> > major = 8, minor = 17, raid_disk = -1,
> > state = 0}, next = 0x0}
> > (gdb) quit
> > A debugging session is active.
> >
> > Inferior 1 [process 6824] will be killed.
> >
> > Quit anyway? (y or n) y
> > tucano:/usr/local/src/mdadm/mdadm-3.2.5#
> >
Thanks for the report.
This is fixed by commit 4687f160276a8f7815675ca758c598d881f04fd7 in mainline
and by commit 0d478e243a90a48fe4da581c7302771f0d66fb3b in the mdadm-3.2.x
branch and thus in mdadm-3.2.6.
NeilBrown
signature.asc
Description: PGP signature
On Fri, 25 Jan 2013 19:05:05 +0200 jari wrote:
> On 2013-01-25 09:54, NeilBrown wrote:
> | On Thu, 24 Jan 2013 15:12:38 +0200 jari wrote:
> |
> | > Hi Neil,
> | >
> | > Would you have any ideas for the *.ps file?
> | > http://bugs.debian.org
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 Thu, 24 Jan 2013 15:12:38 +0200 jari wrote:
> Hi Neil,
>
> Would you have any ideas for the *.ps file?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698846
>
I'm sorry, but I don't understand the question. Maybe you could use more
words?
NeilBrown
signa
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
On Wed, 11 Jul 2012 13:15:38 +0200 Sebastian Hegler
wrote:
> Hi!
>
> Am 11.07.2012 um 04:26 schrieb NeilBrown:
> > I should have asked which kernel you were running.
> > I'm guessing that it is earlier than 2.6.25, and so is mi
e those are the only ones that need to use it.
Adding a test for 'mdstat' being NULL and not trying to call
verify_reshape_position in that case is the simplest fixed I expect, though I
haven't tested yet. Possibly something more thorough is needed.
NeilBrown
signature.asc
Description: PGP signature
able. So
having it reported from SMART would be more sensible.
In brief: mismatch_cnt maybe useful to someone who understands what is means
and is investigating some issues, but it is not something that should be
automatically reported to a casual sysadmin.
NeilBrown
signature.asc
Description: PGP signature
xserver-xorg-core 2:1.12.1.902-1.
Reverting to xserver-xorg-core_1.11.4-1 and related packages
restores a functioning X server.
Thanks,
NeilBrown
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Archite
correctly. I've fixed this upstream so it should filter through
to Debian in due course.
NeilBrown
signature.asc
Description: PGP signature
you don't want email.
The simplest way to get rid of the message might be to add
--syslog
or maybe
$DEAMON_OPTIONS
to the
exec $MDADM --monitor --scan --oneshot
line in /etc/cron.daily/mdadm
I would accept a patch to the documentation to suggest including --syslog in
that example.
NeilBrown
signature.asc
Description: PGP signature
mdadm;a=commitdiff;h=d97a5e60506343bd8cb2b75d5003b2a49cbc8566
Thanks,
NeilBrown
>
> On nonzero mismatch_cnt it makes log entry like this:
> -->8---
> Dec 6 22:52:42 squeeze mdadm[2376]: RebuildFinished event detected on md
> device /dev/md0, component device mismatches found: 128 (on raid
On Sun, 16 Oct 2011 23:42:46 -0400 Daniel Kahn Gillmor
wrote:
> On 10/16/2011 09:55 PM, NeilBrown wrote:
> > On line 1556 for Grow.c you'll find something like:
> >
> > /* FIXME this is added with no justification - why is it here */
> >
56 for Grow.c you'll find something like:
/* FIXME this is added with no justification - why is it here */
ping_monitor(container);
Change that to
if (container)
ping_monitor(container);
and the problem should go awa
spare_sharing = 0;
continue;
case O(MONITOR,'t'): /* test */
test = 1;
This will be in mdadm upstream in the next 24hours.
Thanks for the report.
NeilBrown
signature.asc
Description: PGP signature
#x27;yet'. It seems to imply that md might
improve in support for multipath.
This is not the case. multipath in md is just wrong and will not be extended.
dm-multipath is the only multipath that anyone should use.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
On Sat, 30 Jul 2011 23:09:10 -0400 Scott Schaefer
wrote:
> Verified exists in 3.1.4 and 3.2.2.
>
> Attached patch is against 3.2.2 code.
I have applied this patch to my git tree so it'll appear in the next release.
Thanks,
NeilBrown
http://neil.brown.name/git?p=mdadm;
correct
> Events : 842
>
>
>Device Role : Active device 0
>Array State : AA ('A' == active, '.' == missing)
> flash:~ >
>
> And after a reboot, md2 is flagged as writemostly again.
>
> / Anders
>
This needs to be fixed in
lieve this a "won't fix" issue; one could
> potentially ask for mdadm to do some before/after status-check
> magic and "handle" this and other potential cases in some
> "better" way. Asking it to do so raises a great deal many more
> problems than it
if (posix_memalign((void**)&super, 512,
on line 1291 of super1.c (in the function load_super1) to
if (posix_memalign((void**)&super, 4096,
made any difference.
i.e. get the source, make this change, compile and install. Then
revert the change to mdadm.conf and see if it
ty ???
>
Sometimes wishes come true this issue is fixed in 3.2.2.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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
semble
and send the /tmp/trace output and also your mdadm.conf
Hopefully that will be enough to either determine the problem, or be able
to reproduce it.
Thanks.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscrib
s is really a 'wishlist' issue.
You would like mdadm to notice that the devices have changed size, and tell
md, or maybe would like md to be able to be told immediately when it happens.
Or something like that.
Certainly a good idea.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Sun, 27 Feb 2011 00:04:00 +0100 Christoph Anton Mitterer
wrote:
> Package: mdadm
> Severity: wishlist
>
>
> Hi.
>
> A new upstream version (3.2) is available.
>
Did you read the release notes? Debian should wait for 3.2.1
NeilBrown
--
To UNSUBSCRIBE, email
et of things.
There was a time when a DEVICE line was needed, but that is long gone now.
Thanks,
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Sun, 09 Jan 2011 17:13:10 -0500 Matthew Gabeler-Lee
wrote:
> On 1/9/2011 16:57, NeilBrown wrote:
> > Simply running
> > mdadm --zero-superblock /dev/sdb
> >
> > should fix it.
> Well, that doesn't work very well: "mdadm: Couldn't open /d
On Sun, 09 Jan 2011 22:32:01 +0100 Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 01/09/2011 09:55 PM, NeilBrown wrote:
> > On Sat, 8 Jan 2011 17:53:07 -0500 (EST) Matthew Gabeler-Lee
> > wrote:
> >
> >
> >> On Sat, 8 Jan 201
evices, metadata (presumably)
> > 0.90, two devices have index 0.
What do you mean by "two devices have index 0" ??? I could see nothing in any
of the posts you sent that could be interpreted that way.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.
that was fixed my upstream
commit 303a0e11d0ee136ad8f53f747f3c377daece763b
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=303a0e11d0ee136ad8f53f747f3c377daece763b
NeilBrown
> *pde =
> Oops: [#1] SMP
> last sysfs file: /sys/block/md1/md/sync_action
>
need to
>> find a way to rebuild your initrd.
>>
>
> That's what I expected... any suggestion for doing so ?
>
What I would try would be:
- --create the array
- mount the filesystem
- chroot /mount/point
- mkinitramfs
(or whatever the command is). Maybe it is "m
--assume-clean again but add the --uuid= option there.
If that doesn't work (and I'm not 100% sure it will), you will need to
find a way to rebuild your initrd.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
from that.
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
cessarily
> complicate the script. Thus, I am marking this bug wontfix.
For the record, this is fixed by kernel patch
commit 9744197c3d7b329590c2be33ad7b17409bd798fe
which is in 2.6.28
NeilBrown
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
67 matches
Mail list logo
