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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.