silence an unnescessary raid5 debugging message
PATCH 1/1 silence an unnescessary raid5 debugging message
Hello Ingo,
LVM manages to trigger the "raid5: switching cache buffer size" printk quiet voluminously when using a snapshot device. The following patch disables it by placing it under the debugging PRINTK macro.
-ben
Signature · 14 lines
"Do you seek knowledge in time travel?"
diff -urN linux.orig/drivers/md/raid5.c linux/drivers/md/raid5.c
--- linux.orig/drivers/md/raid5.c Mon Feb 25 14:37:58 2002
+++ linux/drivers/md/raid5.c Tue Oct 8 17:56:43 2002
@@ -282,7 +282,7 @@
}
if (conf->buffer_size != size) {
- printk("raid5: switching cache buffer size, %d --> %d\n", oldsize, size);
+ PRINTK("raid5: switching cache buffer size, %d --> %d\n", oldsize, size);
shrink_stripe_cache(conf);
if (size==0) BUG();
conf->buffer_size = size;Quoted 5 lines · On Tuesday October 8, [email protected] wrote:
Hello Ingo,
LVM manages to trigger the "raid5: switching cache buffer size" printk quiet voluminously when using a snapshot device. The following patch disables it by placing it under the debugging PRINTK macro.
This is there as a 'printk' deliberately. It warns you that what you are doing isn't really supported and will cause a substantial performance hit (as all IO to the array is completely serialised around one of these messages).
If you want to make it PRITNK for yourself, that is fine. But I would rather it stayed as printk in the mainstream kernel untill the root problem is fixed (and I have seen patches that possibly fix the problem, but I haven't had a chance to look at them).
NeilBrown
Quoted 22 lines
-ben
Signature · 3 lines
"Do you seek knowledge in time travel?" diff -urN linux.orig/drivers/md/raid5.c linux/drivers/md/raid5.cdrivers/md/raid5.c +1
-2@@ -282,7 +282,7 @@ }if (conf->buffer_size != size) { -printk ("raid5: switching cache buffer size, %d --> %d\n" , oldsize, size); +PRINTK ("raid5: switching cache buffer size, %d --> %d\n" , oldsize, size);shrink_stripe_cache (conf);if (size==0 )BUG (); conf->buffer_size = size; -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Neil Brown
This is there as a 'printk' deliberately. It warns you that what you are doing isn't really supported and will cause a substantial performance hit (as all IO to the array is completely serialised around one of these messages).
As it stands, the syslogging from the printk does more damage to performance than the underlying problem. Besides, LVM snapshots are slow, but they're useful for a class of problems anyways.
-ben
From: Benjamin LaHaise <[email protected]>
Date: Tue, 8 Oct 2002 19:36:12 -0400
As it stands, the syslogging from the printk does more damage to performance than the underlying problem. Besides, LVM snapshots are slow, but they're useful for a class of problems anyways.
He's just saying kill the real problem first, that's all.
Quoted 8 lines · David S. Miller
From: Benjamin LaHaise <[email protected]>
Date: Tue, 8 Oct 2002 19:36:12 -0400As it stands, the syslogging from the printk does more damage to performance than the underlying problem. Besides, LVM snapshots are slow, but they're useful for a class of problems anyways.
He's just saying kill the real problem first, that's all.
I'm just saying that the message is the only real problem I have with the state of 2.4. Sure, 2.5 deserves it fixed correctly, but I doubt the correct fix will make it into 2.4 anytime soon (it's far more dangerous than we should consider shipping in a "stable" series).
-ben
Signature · 1 line
"Do you seek knowledge in time travel?"
Quoted 8 lines · Benjamin LaHaise
Quoted 7 lines · David S. Miller
From: Benjamin LaHaise <[email protected]>
Date: Tue, 8 Oct 2002 19:36:12 -0400As it stands, the syslogging from the printk does more damage to performance than the underlying problem. Besides, LVM snapshots are slow, but they're useful for a class of problems anyways.
Quoted 6 lines
Quoted 1 line
He's just saying kill the real problem first, that's all.
I'm just saying that the message is the only real problem I have with the state of 2.4. Sure, 2.5 deserves it fixed correctly, but I doubt the correct fix will make it into 2.4 anytime soon (it's far more dangerous than we should consider shipping in a "stable" series).
It sound to me like a big nasty message should be generated when the snapshot volume is created to advise that performance will be horribly impaired. Thrashing the log file to warn the user is like breaking your arm to remind yourself to trim your fingernails.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt