From: Paul Clements <paul.clements@steeleye.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: jejb@steeleye.com, linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes
Date: Tue, 12 Oct 2004 10:06:18 -0400 [thread overview]
Message-ID: <416BE4DA.1040408@steeleye.com> (raw)
In-Reply-To: <16747.15933.68499.915859@cse.unsw.edu.au>
Neil Brown wrote:
>>Paul Clements wrote:
>>itself. Check out the new patch here:
>>
>>http://parisc-linux.org/~jejb/md_bitmap/md_bitmap_2_37_2_6_9_rc2.diff
>>
> Further comments.
>
> bitmap_events
> 1/ You have inserted bitmap_event_hi/lo *before* recovery_cp, thus
> moving recovery_cp, and thus breaking backwards comparability.
Yes. I guess when recovery_cp came along I failed to notice that...
> 2/ The test in hot_add_disk:
> + if (refsb && sb && uuid_equal(sb, refsb) &&
> + sb->events_hi >= refsb->bitmap_events_hi &&
> + sb->events_lo >= refsb->bitmap_events_lo) {
> + bitmap_invalidate = 0;
> is wrong. The events count must be compared as a 64bit
> number. e.g. it is only meaningful to compare events_lo if both
> events_hi are equal.
Yes, that is broken.
> pending_bio_list
> 1/ Do you really need a separate pending_bio_lock, or would
> the current device_lock be adequate to the task.
Probably so...especially with the following change...
> 2/ I think there can be a race with new requests being added to
> this list while bitmap_unplug is running in unplug_slaves.
> I think you should "bio_get_list" before calling bitmap_unplug,
> So that you only then submit requests that were made definitely
> *before* the call the bitmap_unplug. This would have the added
> advantage that you don't need to keep claiming and dropping
> pending_bio_lock.
Yes, that would make sense.
> collection. I would really appreciate it if any further changes could
> be sent as incremental patches, as reading through a large patch like
> that takes a fair bit of effort.
Yes, I certainly understand that. I appreciate all the effort you've put
into reviewing and giving suggestions. Further patches will be on top of
the current bitmap patch.
I will send out an incremental patch to fix the issues above, probably
in a couple of days.
Thanks,
Paul
next prev parent reply other threads:[~2004-10-12 14:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-29 22:51 [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes Paul Clements
2004-01-30 22:52 ` Paul Clements
2004-02-09 2:51 ` Neil Brown
2004-02-09 19:45 ` Paul Clements
2004-02-10 0:04 ` Neil Brown
2004-02-10 16:20 ` Paul Clements
2004-02-10 16:57 ` Paul Clements
2004-02-13 20:58 ` Paul Clements
2004-03-05 5:06 ` Neil Brown
2004-03-05 22:05 ` Paul Clements
2004-03-31 18:38 ` Paul Clements
2004-04-28 18:10 ` Paul Clements
2004-04-28 18:53 ` Peter T. Breuer
2004-04-29 8:41 ` Neil Brown
2004-05-04 20:08 ` Paul Clements
2004-06-08 20:53 ` Paul Clements
2004-06-08 22:47 ` Neil Brown
2004-06-14 23:39 ` Neil Brown
2004-06-14 23:59 ` James Bottomley
2004-06-15 6:27 ` Neil Brown
2004-06-17 17:57 ` Paul Clements
2004-06-18 20:48 ` Paul Clements
2004-06-23 21:48 ` Paul Clements
2004-06-23 21:50 ` Paul Clements
2004-07-06 14:52 ` Paul Clements
[not found] ` <40F7E50F.2040308@steeleye.com>
[not found] ` <16649.61212.310271.36561@cse.unsw.edu.au>
2004-08-10 21:37 ` Paul Clements
2004-08-13 3:04 ` Neil Brown
2004-09-21 3:28 ` Paul Clements
2004-09-21 19:19 ` Paul Clements
2004-10-12 2:15 ` Neil Brown
2004-10-12 14:06 ` Paul Clements [this message]
2004-10-12 21:16 ` Paul Clements
2004-11-10 0:37 ` md: persistent (file-backed) bitmap Neil Brown
2004-11-10 18:28 ` Paul Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=416BE4DA.1040408@steeleye.com \
--to=paul.clements@steeleye.com \
--cc=jejb@steeleye.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).