Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

2008-01-15 Thread Andrew Morton
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

Re: [PATCH 001 of 6] md: Fix an occasional deadlock in raid5

2008-01-15 Thread Andrew Morton
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

Re: [PATCH 001 of 7] md: Support 'external' metadata for md arrays.

2007-12-25 Thread Andrew Morton
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; +

Re: [PATCH 004 of 7] md: Allow devices to be shared between md arrays.

2007-12-25 Thread Andrew Morton
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)

Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)

2007-12-06 Thread Andrew Morton
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

Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)

2007-12-06 Thread Andrew Morton
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

Re: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23

2007-09-21 Thread Andrew Morton
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

Re: md: raid10: fix use-after-free of bio

2007-07-29 Thread Andrew Morton
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

Re: [GIT PATCH 0/2] stripe-queue for 2.6.23 consideration

2007-07-23 Thread Andrew Morton
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

Re: [-mm PATCH 0/2] 74% decrease in dispatched writes, stripe-queue take3

2007-07-13 Thread Andrew Morton
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.

Re: [-mm PATCH 0/2] 74% decrease in dispatched writes, stripe-queue take3

2007-07-13 Thread Andrew Morton
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

Re: [-mm PATCH 0/2] 74% decrease in dispatched writes, stripe-queue take3

2007-07-13 Thread Andrew Morton
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

Re: 2.6.21-mm2 boot failure, raid autodetect, bd_set_size+0xb/0x80

2007-05-11 Thread Andrew Morton
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

Re: [PATCH 002 of 2] md: Improve the is_mddev_idle test

2007-05-10 Thread Andrew Morton
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

Re: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

2007-05-10 Thread Andrew Morton
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

Re: RAID1 out of memory error, was Re: 2.6.21-rc5-mm4

2007-04-05 Thread Andrew Morton
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

Re: [PATCH] md: Avoid a deadlock when removing a device from an md array via sysfs.

2007-04-02 Thread Andrew Morton
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

Re: [PATCH] md: Fix for raid6 reshape.

2007-03-01 Thread Andrew Morton
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

Re: [PATCH 006 of 6] md: Add support for reshape of a raid6

2007-02-21 Thread Andrew Morton
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

Re: [PATCH 006 of 6] md: Add support for reshape of a raid6

2007-02-21 Thread Andrew Morton
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

Re: [PATCH 006 of 6] md: Add support for reshape of a raid6

2007-02-21 Thread Andrew Morton
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

Re: Kernel 2.6.19.2 New RAID 5 Bug (oops when writing Samba - RAID5)

2007-01-26 Thread Andrew Morton
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.

Re: [PATCH 002 of 4] md: Make 'repair' actually work for raid1.

2007-01-23 Thread Andrew Morton
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), +

Re: 2.6.20-rc5: cp 18gb 18gb.2 = OOM killer, reproducible just like 2.16.19.2

2007-01-22 Thread Andrew Morton
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

Re: 2.6.20-rc5: cp 18gb 18gb.2 = OOM killer, reproducible just like 2.16.19.2

2007-01-22 Thread Andrew Morton
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

Re: [patch] md: pass down BIO_RW_SYNC in raid{1,10}

2007-01-08 Thread Andrew Morton
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,

Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]

2006-12-19 Thread Andrew Morton
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)

Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]

2006-12-17 Thread Andrew Morton
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

Re: md patches in -mm

2006-12-15 Thread Andrew Morton
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).

Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]

2006-12-15 Thread Andrew Morton
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

Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]

2006-12-15 Thread Andrew Morton
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

Re: [PATCH 002 of 6] md: Change lifetime rules for 'md' devices.

2006-10-31 Thread Andrew Morton
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

Re: [PATCH 001 of 4] md: Define backing_dev_info.congested_fn for raid0 and linear

2006-08-28 Thread Andrew Morton
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

Re: [PATCH 000 of 4] md: Introduction

2006-08-24 Thread Andrew Morton
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

Re: [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks.

2006-05-15 Thread Andrew Morton
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

Re: [PATCH 001 of 3] md: Change md/bitmap file handling to use bmap to file blocks-fix

2006-05-15 Thread Andrew Morton
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

Re: [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks.

2006-05-14 Thread Andrew Morton
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

Re: [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks.

2006-05-13 Thread Andrew Morton
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

Re: [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks.

2006-05-13 Thread Andrew Morton
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

Re: [PATCH 002 of 8] md/bitmap: Remove bitmap writeback daemon.

2006-05-12 Thread Andrew Morton
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()

Re: [PATCH 008 of 8] md/bitmap: Change md/bitmap file handling to use bmap to file blocks.

2006-05-12 Thread Andrew Morton
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

Re: [PATCH 004 of 11] md: Increase the delay before marking metadata clean, and make it configurable.

2006-05-01 Thread Andrew Morton
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

Re: [PATCH 004 of 11] md: Increase the delay before marking metadata clean, and make it configurable.

2006-04-30 Thread Andrew Morton
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

Re: [PATCH 001 of 3] md: Don't clear bits in bitmap when writing to one device fails during recovery.

2006-03-29 Thread Andrew Morton
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 { +

Re: [PATCH 005 of 13] md: Allow stripes to be expanded in preparation for expanding an array.

2006-03-16 Thread Andrew Morton
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

Re: [PATCH 005 of 13] md: Allow stripes to be expanded in preparation for expanding an array.

2006-03-16 Thread Andrew Morton
NeilBrown [EMAIL PROTECTED] wrote: + wait_event_lock_irq(conf-wait_for_stripe, +!list_empty(conf-inactive_list), +conf-device_lock, +unplug_slaves(conf-mddev); +

Re: [PATCH 005 of 13] md: Allow stripes to be expanded in preparation for expanding an array.

2006-03-16 Thread Andrew Morton
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 =

Re: [PATCH 006 of 13] md: Infrastructure to allow normal IO to continue while array is expanding.

2006-03-16 Thread Andrew Morton
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,

Re: [PATCH 007 of 13] md: Core of raid5 resize process

2006-03-16 Thread Andrew Morton
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)) +

Re: [PATCH 010 of 13] md: Only checkpoint expansion progress occasionally.

2006-03-16 Thread Andrew Morton
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

Re: [PATCH md 013 of 20] Count corrected read errors per drive.

2005-12-12 Thread Andrew Morton
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

Re: [PATCH md 002 of 14] Allow raid1 to check consistency

2005-12-05 Thread Andrew Morton
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

Re: [PATCH md 006 of 14] Make /proc/mdstat pollable.

2005-12-01 Thread Andrew Morton
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

Re: [PATCH md 008 of 14] Convert md to use kzalloc throughout

2005-12-01 Thread Andrew Morton
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),

Re: [PATCH md 010 of 14] Convert various kmap calls to kmap_atomic

2005-12-01 Thread Andrew Morton
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

Re: [PATCH md 002 of 2] Make md threads interruptible again.

2005-11-14 Thread Andrew Morton
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)) +

Re: File corruption on LVM2 on top of software RAID1

2005-08-05 Thread Andrew Morton
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

Re: File corruption on LVM2 on top of software RAID1

2005-08-04 Thread Andrew Morton
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

Re: [PATCH md 000 of 7] Introduction

2005-08-03 Thread Andrew Morton
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

Re: [PATCH md 000 of 7] Introduction

2005-08-03 Thread Andrew Morton
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

Re: [PATCH md 001 of 2] Close a small race in md thread deregistration

2005-04-07 Thread Andrew Morton
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 (setting

Re: [PATCH md 0 of 12] Introduction

2005-03-23 Thread Andrew Morton
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

Re: [PATCH md 0 of 12] Introduction

2005-03-23 Thread Andrew Morton
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

Re: [PATCH md 0 of 4] Introduction

2005-03-07 Thread Andrew Morton
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

Fw: [Bugme-new] [Bug 4211] New: md configuration destroys disk GPT label

2005-02-14 Thread Andrew Morton
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

Re: [PATCH md 6 of 6] Fix handling of overlapping requests in raid5

2005-02-07 Thread Andrew Morton
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

Re: [PATCH md 6 of 6] Fix handling of overlapping requests in raid5

2005-02-07 Thread Andrew Morton
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) { - -