Re: possible bug with RAID

Re: possible bug with RAID

[Roy Sigurd Karlsbakk]

> it would be interesting to write a simple benchmark
> that simply reads a file at a fixed rate.  *that* would
> actually simulate your app.

sure. I'm using tux+wget for that. I were just playing around with dd

> sounds like a VM/balance problem.  you didn't mention which kernel
> you're using.

2.4.16 w/tux + xfs. The fs used on the raid vol is xfs

> > I tried to do the bechmark with the individual drives, and no problem
> > there...
>
> much less bandwidth, and therefore VM pressure.

ok
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA

Computers are like air conditioners.
They stop working when you open Windows.

Re: possible bug with RAID

[Steve Lord]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Tue, 2001-12-11 at 12:54, Roy Sigurd Karlsbakk wrote:
> > it would be interesting to write a simple benchmark
> > that simply reads a file at a fixed rate.  *that* would
> > actually simulate your app.
> 
> sure. I'm using tux+wget for that. I were just playing around with dd
> 
> > sounds like a VM/balance problem.  you didn't mention which kernel
> > you're using.
> 
> 2.4.16 w/tux + xfs. The fs used on the raid vol is xfs

We just got to the bottom of a problem in xfs which was causing memory
not to get cleaned as efficiently as it should be - it lead to dbench
lockups on low memory systems. It is possible you are seeing a similar
effect - we dirty all the memory and then struggle to clean it up.

Try the attached patch.

Steve



[-- Attachment #2: xfs.patch --]
[-- Type: text/plain, Size: 1671 bytes --]


===========================================================================
Index: linux/fs/buffer.c
===========================================================================

--- /usr/tmp/TmpDir.12499-0/linux/fs/buffer.c_1.96	Tue Dec 11 13:33:26 2001
+++ linux/fs/buffer.c	Tue Dec 11 13:31:17 2001
@@ -224,6 +224,7 @@
 	unlock_buffer(bh);
 	put_bh(bh);
 }
+EXPORT_SYMBOL(end_buffer_io_sync);
 
 /*
  * The buffers have been marked clean and locked.  Just submit the dang
@@ -2538,7 +2539,7 @@
 /*
  * Can the buffer be thrown out?
  */
-#define BUFFER_BUSY_BITS	((1<<BH_Dirty) | (1<<BH_Lock))
+#define BUFFER_BUSY_BITS	((1<<BH_Dirty) | (1<<BH_Lock) | (1<<BH_Delay))
 #define buffer_busy(bh)		(atomic_read(&(bh)->b_count) | ((bh)->b_state & BUFFER_BUSY_BITS))
 
 /*

===========================================================================
Index: linux/fs/pagebuf/page_buf_io.c
===========================================================================

--- /usr/tmp/TmpDir.12499-0/linux/fs/pagebuf/page_buf_io.c_1.102	Tue Dec 11 13:33:26 2001
+++ linux/fs/pagebuf/page_buf_io.c	Tue Dec 11 10:22:58 2001
@@ -1337,10 +1337,12 @@
 	head = bh;
 	do {
 		lock_buffer(bh);
-		set_buffer_async_io(bh);
-		set_bit(BH_Uptodate, &bh->b_state);
-		clear_bit(BH_Dirty, &bh->b_state);
 		clear_bit(BH_Delay, &bh->b_state);
+		if (atomic_set_buffer_clean(bh)) {
+			get_bh(bh);
+			bh->b_end_io = end_buffer_io_sync;
+			refile_buffer(bh);
+		}
 		bh = bh->b_this_page;
 	} while (bh != head);
 
@@ -1350,6 +1352,7 @@
 	} while (bh != head);
 
 	SetPageUptodate(page);
+	UnlockPage(page);
 	page_cache_release(page);
 }
 

Re: possible bug with RAID

[Steve Lord]

On Tue, 2001-12-11 at 13:34, Steve Lord wrote:
> On Tue, 2001-12-11 at 12:54, Roy Sigurd Karlsbakk wrote:
> > > it would be interesting to write a simple benchmark
> > > that simply reads a file at a fixed rate.  *that* would
> > > actually simulate your app.
> > 
> > sure. I'm using tux+wget for that. I were just playing around with dd
> > 
> > > sounds like a VM/balance problem.  you didn't mention which kernel
> > > you're using.
> > 
> > 2.4.16 w/tux + xfs. The fs used on the raid vol is xfs
> 
> We just got to the bottom of a problem in xfs which was causing memory
> not to get cleaned as efficiently as it should be - it lead to dbench
> lockups on low memory systems. It is possible you are seeing a similar
> effect - we dirty all the memory and then struggle to clean it up.
> 
> Try the attached patch.
> 
> Steve
> 

OK, don't try that patch too hard, I have a better one without a race
condition on the buffer head.... it should show up in the xfs cvs tree
later today, I am going to stress this one a little harder first!

Steve

possible bug with RAID

[Roy Sigurd Karlsbakk]

hi

I have this pc with a promise udma133 tx2 controller, having one 120G
drive per channel. I'm benchmarking this, using some 50 'dd if=file[1..50]
of=/dev/null' to simuate my application. This will work for a few seconds,
giving me pretty good i/o speed, but then all the processes go defunct and
stay like that some minutes (i really don't know how long).

I tried to do the bechmark with the individual drives, and no problem
there...

Anyone have a clue?

Configuration:
- Promise 133 TX2 (20269 manually patched in. Just made som defines to
  alias it to the 20268)
- 2 WD1200BB drives (hde and hdg)

/etc/raidtab:

raiddev /dev/md0
	raid-level              0
	nr-raid-disks           2
	persistent-superblock   0
	chunk-size              4096

	device                  /dev/hde
	raid-disk               0
	device                  /dev/hdg
	raid-disk               1

--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA

Computers are like air conditioners.
They stop working when you open Windows.