On Thu, 17 Jan 2008 16:23:30 +0100 Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 01/17/2008 11:35 AM, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
>
> still the same md issue (do_md_run returns -22=E
On Wed, 16 Jan 2008 00:09:31 -0700 "Dan Williams" <[EMAIL PROTECTED]> wrote:
> > heheh.
> >
> > it's really easy to reproduce the hang without the patch -- i could
> > hang the box in under 20 min on 2.6.22+ w/XFS and raid5 on 7x750GB.
> > i'll try with ext3... Dan's experiences suggest it won't h
On Tue, 15 Jan 2008 21:01:17 -0800 (PST) dean gaudet <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Jan 2008, NeilBrown wrote:
>
> >
> > raid5's 'make_request' function calls generic_make_request on
> > underlying devices and if we run out of stripe heads, it could end up
> > waiting for one of those r
On Fri, 14 Dec 2007 17:26:28 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> + mddev_unlock(rdev->mddev);
> + ITERATE_MDDEV(mddev, tmp) {
> + mdk_rdev_t *rdev2;
> +
> + mddev_lock(mddev);
> + ITERATE_RDEV(mddev, rdev2
On Fri, 14 Dec 2007 17:26:08 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> + if (strncmp(buf, "external:", 9) == 0) {
> + int namelen = len-9;
> + if (namelen >= sizeof(mddev->metadata_type))
> + namelen = sizeof(mddev->metadata_type)-1;
> +
On Thu, 6 Dec 2007 17:38:08 -0500 (EST)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Andrew Morton wrote:
>
> > On Sat, 1 Dec 2007 06:26:08 -0500 (EST)
> > Justin Piszcz <[EMAIL PROTECTED]> wrote:
> >
> >> I am putting a
On Sat, 1 Dec 2007 06:26:08 -0500 (EST)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
> I am putting a new machine together and I have dual raptor raid 1 for the
> root, which works just fine under all stress tests.
>
> Then I have the WD 750 GiB drive (not RE2, desktop ones for ~150-160 on
> sale n
On Thu, 20 Sep 2007 18:27:35 -0700
Dan Williams <[EMAIL PROTECTED]> wrote:
> Fix a couple bugs and provide documentation for the async_tx api.
>
> Neil, please 'ack' patch #3.
>
> git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus
Well it looks like Neil is on vacation or is
On Fri, 27 Jul 2007 16:46:23 +0200 Maik Hampel <[EMAIL PROTECTED]> wrote:
> In case of read errors raid10d tries to print a nice error message,
> unfortunately using data from an already put bio.
>
> Signed-off-by: Maik Hampel <[EMAIL PROTECTED]>
>
> diff --git a/drivers/md/raid10.c b/drivers/md
On Sun, 22 Jul 2007 02:44:52 -0700
Dan Williams <[EMAIL PROTECTED]> wrote:
> The stripe-queue patches are showing solid performance improvement.
>
> git://lost.foo-projects.org/~dwillia2/git/iop md-for-linus
It's a slippery little tree that one. I was using md-accel-linus, only I
nuked it
On Fri, 13 Jul 2007 16:28:30 -0700
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Andrew Morton [mailto:[EMAIL PROTECTED]
> >
> > But your ongoing maintenance activity will continue to be held in
> those
>
On Fri, 13 Jul 2007 15:57:26 -0700
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Andrew Morton [mailto:[EMAIL PROTECTED]
> > > The following patches replace the stripe-queue patches currently in
> -mm.
> >
On Fri, 13 Jul 2007 15:35:42 -0700
Dan Williams <[EMAIL PROTECTED]> wrote:
> The following patches replace the stripe-queue patches currently in -mm.
I have a little practical problem here: am presently unable to compile
anything much due to all the git rejects coming out of git-md-accel.patch.
On Tue, 12 Jun 2007 10:41:03 -0700
Dan Williams <[EMAIL PROTECTED]> wrote:
> Most of the raid5 code predates git so the coding style violations have
> been present for a long time. However, now that major new patches are
> arriving, checkpatch.pl complains about these old violations. Instead of
On Fri, 11 May 2007 20:03:34 +0200
[EMAIL PROTECTED] wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, May 09, 2007 at 01:23:22AM -0700
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm2/
> >
> >
> It won&
On Thu, 10 May 2007 16:51:31 +0200 (MEST) Jan Engelhardt <[EMAIL PROTECTED]>
wrote:
> On May 9 2007 18:51, Linus Torvalds wrote:
> >
> >(But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is probably
> >some strange mixup of Andrew Morton and An
On Thu, 10 May 2007 16:22:31 +1000 NeilBrown <[EMAIL PROTECTED]> wrote:
> The test currently looks for any (non-fuzz) difference, either
> positive or negative. This clearly is not needed. Any non-sync
> activity will cause the total sectors to grow faster than the sync_io
> count (never slower)
On Fri, 06 Apr 2007 02:33:03 +1000
Reuben Farrelly <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 3/04/2007 3:47 PM, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
> >
> > - The oops in git-net.patch
On Mon, 2 Apr 2007 17:44:17 +1000 NeilBrown <[EMAIL PROTECTED]> wrote:
> (This patch should go in 2.6.21 as it fixes a recent regression - NB)
>
> A device can be removed from an md array via e.g.
> echo remove > /sys/block/md3/md/dev-sde/state
>
> This will try to remove the 'dev-sde' subtree
On Fri, 2 Mar 2007 15:56:55 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> - conf->expand_progress = (sector_nr + i)*(conf->raid_disks-1);
> + conf->expand_progress = (sector_nr + i) * new_data_disks);
ahem.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body
On Thu, 22 Feb 2007 13:39:56 +1100 Neil Brown <[EMAIL PROTECTED]> wrote:
> I must right code that Andrew can read.
That's write.
But more importantly, things that people can immediately see and understand
help reduce the possibility of mistakes. Now and in the future.
If we did all loops like
On Thu, 22 Feb 2007 00:36:22 +0100
Oleg Verych <[EMAIL PROTECTED]> wrote:
> > From: Andrew Morton
> > Newsgroups: gmane.linux.raid,gmane.linux.kernel
> > Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> > Date: Wed, 21 Feb 2007 14:48:06 -0800
On Tue, 20 Feb 2007 17:35:16 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> + for (i = conf->raid_disks ; i-- ; ) {
That statement should be dragged out, shot, stomped on then ceremonially
incinerated.
What's wrong with doing
for (i = 0; i < conf->raid_disks; i++) {
in a man
On Wed, 24 Jan 2007 18:37:15 -0500 (EST)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
> > Without digging too deeply, I'd say you've hit the same bug Sami Farin and
> > others
> > have reported starting with 2.6.19: pages mapped with kmap_atomic() become
> > unmapped
> > during memcpy() or similar ope
On Tue, 23 Jan 2007 11:26:52 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> + for (j = 0; j < vcnt ; j++)
> +
> memcpy(page_address(sbio->bi_io_vec[j].bv_page),
> +
>
On Tue, 23 Jan 2007 11:37:09 +1100
Donald Douwsma <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >> On Sun, 21 Jan 2007 14:27:34 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]>
> >> wrote:
> >> Why does copying an 18GB on a 74GB raptor raid1 cause the
> On Sun, 21 Jan 2007 14:27:34 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]>
> wrote:
> Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
> the OOM killer and kill all of my processes?
What's that? Software raid or hardware raid? If the latter, which driver?
> Doing
On Mon, 8 Jan 2007 10:08:34 +0100
Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> md raidX make_request functions strip off the BIO_RW_SYNC flag,
> thus introducing additional latency.
>
> fixing this in raid1 and raid10 seems to be straight forward enough.
>
> for our particular usage case in DRBD,
On Tue, 19 Dec 2006 15:26:00 -0800 (PST)
Luben Tuikov <[EMAIL PROTECTED]> wrote:
> The reason was that my dev tree was tainted by this bug:
>
> if (good_bytes &&
> - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> + scsi_end_request(cmd, 1, good_bytes, result
On Sun, 17 Dec 2006 12:00:12 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> Okay, I have identified the patch that causes the problem to appear, which is
>
> fix-sense-key-medium-error-processing-and-retry.patch
>
> With this patch reverted -rc1-mm1 is happily running on my test box.
Th
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Jeff, I shall send all the sata patches which I have at you one single time
> and I shall then drop the lot. So please don't flub them.
>
> I'll then do a rc1-mm2 without them.
hm, this i
On Sat, 16 Dec 2006 07:50:01 +1100
Neil Brown <[EMAIL PROTECTED]> wrote:
> On Friday December 15, [EMAIL PROTECTED] wrote:
> > From: Neil Brown <[EMAIL PROTECTED]>
> > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
> > > i.e. current -mm is good for 2.6.20 (though I have a few other little
> > > thin
On Fri, 15 Dec 2006 20:21:46 +0100
[EMAIL PROTECTED] wrote:
> From: Neil Brown <[EMAIL PROTECTED]>
> Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
> > i.e. current -mm is good for 2.6.20 (though I have a few other little
> > things I'll be sending in soon, they aren't related to the raid6
> > proble
On Fri, 8 Dec 2006 12:05:24 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> Following are 5 patches for md in 2.6.19-rc6-mm2 that are suitable for 2.6.20.
>
> Patch 4 might fix an outstanding bug against md which manifests as an
> oops early in boot, but I don't have test results yet.
>
> NeilBrown
On Tue, 31 Oct 2006 17:00:51 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> Currently md devices are created when first opened and remain in existence
> until the module is unloaded.
> This isn't a major problem, but it somewhat ugly.
>
> This patch changes the lifetime rules so that an md device w
On Tue, 29 Aug 2006 15:39:24 +1000
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> Each backing_dev needs to be able to report whether it is congested,
> either by modulating BDI_*_congested in ->state, or by
> defining a ->congested_fn.
> md/raid did neither of these. This patch add a congested_fn
> w
On Thu, 24 Aug 2006 17:40:56 +1000
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> Following are 4 patches against 2.6.18-rc4-mm2
>
> The first 2 are bug fixes which should go in 2.6.18, and apply
> equally well to that tree as to -mm.
>
> The latter two should stay in -mm until after 2.6.18.
>
> The
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> +do_sync_file_range(file, 0, LLONG_MAX,
> + SYNC_FILE_RANGE_WRITE |
> + SYNC_FILE_RANGE_WAIT_AFTER);
That needs a SYNC_FILE_RANGE_WAIT_BEFORE too. Otherwise any dirty,
under-writeba
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> ...
>
> > > I have a patch which did that,
> > > but decided that the possibility of kmalloc failure at awkward times
> > > would make that not suitable.
> >
> > submit_bh() can and will allocate memory, although most decent device
> > drivers should be
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Saturday May 13, [EMAIL PROTECTED] wrote:
> > Paul Clements <[EMAIL PROTECTED]> wrote:
> > >
> > > Andrew Morton wrote:
> > >
> > > > The loss of pagecache coherency seems sad. I assume
Paul Clements <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > The loss of pagecache coherency seems sad. I assume there's never a
> > requirement for userspace to read this file.
>
> Actually, there is. mdadm reads the bitmap file, so that woul
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Friday May 12, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > > If md is asked to store a bitmap in a file, it tries to hold onto the
> > > page cache pages for that file, manipulate them directly, and call a
> > > cocktail o
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Friday May 12, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > > ./drivers/md/bitmap.c | 115
> > > ++
> >
> > hmm. I hope we're not doing any of that filesystem I/O within t
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> If md is asked to store a bitmap in a file, it tries to hold onto the
> page cache pages for that file, manipulate them directly, and call a
> cocktail of operations to write the file out. I don't believe this is
> a supportable approach.
erk. I think it'
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> ./drivers/md/bitmap.c | 115
> ++
hmm. I hope we're not doing any of that filesystem I/O within the context
of submit_bio() or kblockd or anything like that. Looks OK from a quick
scan.
a_ops->commit_writ
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Sunday April 30, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > When a md array has been idle (no writes) for 20msecs it is marked as
> > > 'clean'. This delay turns out to be too short for some real
> > > wo
NeilBrown <[EMAIL PROTECTED]> wrote:
>
>
> When a md array has been idle (no writes) for 20msecs it is marked as
> 'clean'. This delay turns out to be too short for some real
> workloads. So increase it to 200msec (the time to update the metadata
> should be a tiny fraction of that) and make it
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + if (!uptodate) {
> +int sync_blocks = 0;
> +sector_t s = r1_bio->sector;
> +long sectors_to_go = r1_bio->sectors;
> +/* make sure these bits doesn't get cleared. */
> +do {
> +
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> diff ./drivers/md/raid5.c~current~ ./drivers/md/raid5.c
> --- ./drivers/md/raid5.c~current~2006-03-17 11:48:58.0 +1100
> +++ ./drivers/md/raid5.c 2006-03-17 11:48:58.0 +1100
> @@ -1747,8 +1747,9 @@ static int make_request(request_q
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> @@ -4539,7 +4543,9 @@ static void md_do_sync(mddev_t *mddev)
>*/
> max_sectors = mddev->resync_max_sectors;
> mddev->resync_mismatches = 0;
> -} else
> +} else if (test_bit(MD_RECOVERY_RESHAPE, &mddev->re
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> -retry:
> prepare_to_wait(&conf->wait_for_overlap, &w,
> TASK_UNINTERRUPTIBLE);
> -sh = get_active_stripe(conf, new_sector, pd_idx,
> (bi->bi_rw&RWA_MASK));
> +sh = get_active_stripe(conf, new_sector, disks, pd_
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + /* Got them all.
> + * Return the new ones and free the old ones.
> + * At this point, we are holding all the stripes so the array
> + * is completely stalled, so now is a good time to resize
> + * conf->disks.
> + */
> +n
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + wait_event_lock_irq(conf->wait_for_stripe,
> +!list_empty(&conf->inactive_list),
> +conf->device_lock,
> +unplug_slaves(conf->mddev);
> +
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> +static int resize_stripes(raid5_conf_t *conf, int newsize)
> +{
> +/* make all the stripes able to hold 'newsize' devices.
> + * New slots in each stripe get 'page' set to a new page.
> + * We allocate all the new stripes first, then if that
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + errors
> +An approximate count of read errors that have been detected on
> +this device but have not caused the device to be evicted from
> +the array (either because they were corrected or because they
> +happened whil
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> Would you accept:
> --
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
>
> ### Diffstat output
> ./mm/swap.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff ./mm/swap.c~current~ ./mm/swap.c
> --- ./mm/swap.c~current~ 2005
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + paddr = kmap_atomic(page, KM_USER0);
> +memset(paddr + offset, 0xff,
> PAGE_SIZE - offset);
This page which is being altered is a user-visible one, no? A pageca
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> - conf = kmalloc (sizeof (*conf) + mddev->raid_disks*sizeof(dev_info_t),
> +conf = kzalloc (sizeof (*conf) + mddev->raid_disks*sizeof(dev_info_t),
> -new = (mddev_t *) kmalloc(sizeof(*new), GFP_KERNEL);
> +new = (mddev_t *) kzalloc(sizeof(
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> +DECLARE_WAIT_QUEUE_HEAD(md_event_waiters);
>
static scope?
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + if (test_bit(MD_RECOVERY_REQUESTED, &pi->mddev->recovery))
> +j = pi->raid_disks;
> +else
> +j = 1;
> +while(j--) {
> +bio = r1_bio->bios[j];
> +for (i = 0; i < RESYNC_PAGES; i++) {
> +
NeilBrown <[EMAIL PROTECTED]> wrote:
>
>
> Despite the fact that md threads don't need to be signalled, and won't
> respond to signals anyway, we need to have an 'interruptible' wait,
> else they stay in 'D' state and add to the load average.
>
> ...
> + if (signal_pending(current))
>
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Sunday October 30, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > I'd like to review the sysfs a bit more before it goes to Linus, but
> > > the rest can go anytime.
> >
> > umm, what does "the sysfs" refer to?
>
NeilBrown <[EMAIL PROTECTED]> wrote:
>
>
> I'd like to review the sysfs a bit more before it goes to Linus, but
> the rest can go anytime.
umm, what does "the sysfs" refer to?
Current md patches in -mm:
md-better-handling-of-readerrors-with-raid5.patch
md-initial-sysfs-support-for-md.patch
md
"Simon Matter" <[EMAIL PROTECTED]> wrote:
>
> While looking at some data corruption vulnerability reports on
> Securityfocus I wonder why this issue does not get any attention from
> distributors. I have an open bugzilla report with RedHat, have an open
> customer service request with RedHat, ha
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the
> bug which this fix addresses.
aargh, I see that it did fix it.
Don't blame me. Blame people who screw up list threading by reading a
mail-&g
"Simon Matter" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Please CC me as I'm not subscribed to the kernel list.
>
> I had a hard time identifying a serious problem in the 2.6 linux kernel.
Yes, it is a serious problem.
> It all started while evaluating RHEL4 for new servers. My data integrity
> te
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Wednesday August 3, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Following are 7 patches for md in 2.6.13-rc4
> > > They are all fairly well tested, with the possible exception of '4' -
> > > I haven't actually tri
NeilBrown <[EMAIL PROTECTED]> wrote:
>
>
> Following are 7 patches for md in 2.6.13-rc4
> They are all fairly well tested, with the possible exception of '4' -
> I haven't actually tried throwing BIO_RW_BARRIER requests are any md
> devices. However the code is very straight forward.
>
> I'm hap
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> There is a tiny race when de-registering an MD thread, in that the
> thread could disappear before it is set a SIGKILL, causing
> send_sig to have problems.
> This is most easily closed by holding tasklist_lock between
> enabling the thread to exit (s
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Of course it doesn't always work out that simply ;)
>
> In this case it's not clear that a tsort will work out right. I'll take a
> look.
Well it wasn't completely clean, and I forgot to rename the patches,
NeilBrown <[EMAIL PROTECTED]> wrote:
>
>
> Andrew: Are you happy to keep collecting these as a list of patches
> (bugs followed by bug-fixes :-), or would it be easier if I merged all
> the bug fixes into earlier patches and just resent a small number of
> "add-functionality" patches??
What I
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> The first two are trivial and should apply equally to 2.6.11
>
> The second two fix bugs that were introduced by the recent
> bitmap-based-intent-logging patches and so are not relevant
> to 2.6.11 yet.
The changelog for the "Fix typo in super_1_sync"
Begin forwarded message:
Date: Mon, 14 Feb 2005 05:29:22 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 4211] New: md configuration destroys disk GPT label
http://bugme.osdl.org/show_bug.cgi?id=4211
Summary: md configuration destroys disk GPT label
Neil Brown <[EMAIL PROTECTED]> wrote:
>
> On Monday February 7, [EMAIL PROTECTED] wrote:
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > > + retry:
> > > sh = get_active_stripe(conf, new_sector, pd_idx,
> > > (bi->bi_rw&RWA_MASK));
> > > if (sh) {
> > > -
>
NeilBrown <[EMAIL PROTECTED]> wrote:
>
> + retry:
> sh = get_active_stripe(conf, new_sector, pd_idx,
> (bi->bi_rw&RWA_MASK));
> if (sh) {
> -
> -while (!add_stripe_bio(sh, bi, dd_idx,
> (bi->bi_rw&RW_MASK))) {
> -/
Mike Black wrote:
>
> 2.2.6-pre6 with ext3-2.4-0.0.8-246p5
> System is a dual PIII/1Ghz 2G memory
> Qlogic 2100 Fibre Channel
>
> This is on a raid5 -- since both linux version and ext3 were changes not
> sure which is the cause yet. I'm waiting for resync to finish to try it on
> ext2.
Could
76 matches
Mail list logo
