linux-kernel - Re: [RFC][PATCH] md: avoid fullsync if a faulty member missed a dirty transition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <170fa0d20805082208y5ad10fe6xbbbaddcbcb7a4736@mail.gmail.com>
Date:	Fri, 9 May 2008 01:08:40 -0400
From:	"Mike Snitzer" <snitzer@...il.com>
To:	"Neil Brown" <neilb@...e.de>
Cc:	linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
	paul.clements@...eleye.com
Subject: Re: [RFC][PATCH] md: avoid fullsync if a faulty member missed a dirty transition

On Fri, May 9, 2008 at 12:42 AM, Mike Snitzer <snitzer@...il.com> wrote:

>  Was I supposed to use this latest patch in combination with your
>  previous patch (to validate_super)?  Because you'll note that with
>  your most recent patch nbd0's events (ev1) is still one less than
>  sdq's events_cleared.  As such the validate_super's "ev1 <
>  mddev->bitmap->events_cleared" check triggers a full rebuild.
>
>  The kernel log shows:
>  md: md0 stopped.
>  md: bind<nbd0>
>  md: bind<sdq>
>  md: kicking non-fresh nbd0 from array!
>  md: unbind<nbd0>
>  md: export_rdev(nbd0)
>  raid1: raid set md0 active with 1 out of 2 mirrors
>  md0: bitmap initialized from disk: read 13/13 pages, set 0 bits, status: 0

Also, no bits were set in the bitmap.. bitmap_create() must've thrown
away the dirty bits.  Given your latest patch, does bitmap_create()'s
"bitmap->events_cleared == mddev->events" check need to be adjusted?

Before I would always see something like:
md0: bitmap initialized from disk: read 13/13 pages, set 1 bits, status: 0

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/