NeilBrown [EMAIL PROTECTED] wrote:
+ retry:
sh = get_active_stripe(conf, new_sector, pd_idx,
(bi-bi_rwRWA_MASK));
if (sh) {
-
-while (!add_stripe_bio(sh, bi, dd_idx,
(bi-bi_rwRW_MASK))) {
-/* add failed
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_rwRWA_MASK));
if (sh) {
-
-
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
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 patch
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'll
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, but
this is how the tsort came out:
md-merge
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 happy (even
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 tried throwing
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
tests gave me
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, have
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))
+
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:
- 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(*new),
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 pagecache
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-12-06
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 while the
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:
+ wait_event_lock_irq(conf-wait_for_stripe,
+!list_empty(conf-inactive_list),
+conf-device_lock,
+unplug_slaves(conf-mddev);
+
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.
+ */
+ndisks =
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_rwRWA_MASK));
+sh = get_active_stripe(conf, new_sector, disks, pd_idx,
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-recovery))
+
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_queue_t
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:
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
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
workloads. So increase
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_write()
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's
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 of operations to
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 would be
broken. Also, it's just useful for a user
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 there's never a
requirement for userspace to read this file.
Actually
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 OK.
submit_bh
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-writeback
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 second
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
which
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 will
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
problem).
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
things I'll be
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 is looking like a lot of work
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.
That was
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 == 0)
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 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 this
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 kernel to invoke
the OOM killer and kill all of my
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 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 operations.
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 manner
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
Hallo.
On Tue, 20 Feb 2007 17:35:16
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 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 of a
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 which
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 has been fixed, so that tree has been restored
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) so
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 Andi Kleen in your mind ;)
What do the letters
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't boot here.
AMD64 platform, raid6 partition
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 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.
I have a little practical problem here: am presently unable
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
trees, won't it?
For now:
git://lost.foo-projects.org
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, 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/raid10.c
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 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 now
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 new machine together and I have dual raptor raid 1 for the
root
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 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, tmp2)
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 requests to
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 happen with
66 matches
Mail list logo
