[path 2.6] reduce ext3 log spamming (blank lines)

[path 2.6] reduce ext3 log spamming (blank lines)

[David Brownell]

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

When drives go offline, e.g. usb-storage disconnect, the
upper layers don't behave very intelligently yet:  ext3
over scsi keeps retrying reads, logging three lines for
each error:

10:58:31  scsi0 (0:0): rejecting I/O to dead device
10:58:31  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:58:31  
10:58:55  scsi0 (0:0): rejecting I/O to dead device
10:58:55  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:58:55  
10:59:30  scsi0 (0:0): rejecting I/O to dead device
10:59:30  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:30  
10:59:30  scsi0 (0:0): rejecting I/O to dead device
10:59:30  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:30  
10:59:30  scsi0 (0:0): rejecting I/O to dead device
10:59:30  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:30  
10:59:32  scsi0 (0:0): rejecting I/O to dead device
10:59:32  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:32  
10:59:32  scsi0 (0:0): rejecting I/O to dead device
10:59:32  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:32  
10:59:33  scsi0 (0:0): rejecting I/O to dead device
10:59:33  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:33  
10:59:47  scsi0 (0:0): rejecting I/O to dead device
10:59:47  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:47  
10:59:48  scsi0 (0:0): rejecting I/O to dead device
10:59:48  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:48  
10:59:49  scsi0 (0:0): rejecting I/O to dead device
10:59:49  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:59:49  
11:00:07  scsi0 (0:0): rejecting I/O to dead device
11:00:07  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
11:00:07  

This patch shrinks that log spam by the trivial third, getting
rid of those needless blank lines.  It's not clear to me why
the "no such device" errors don't immediately make ext3
(or is it the block layer?) give up ... maybe someone else
can make Linux not retry after those errors.

- Dave


[-- Attachment #2: ext3.patch --]
[-- Type: text/x-diff, Size: 581 bytes --]

Prevent one ext3 error report from spamming dmesg/syslog with blank lines;
ext3_error() already includes the necessary newline.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- 1.59/fs/ext3/namei.c	Tue Oct 19 02:40:30 2004
+++ edited/fs/ext3/namei.c	Tue Dec  7 14:28:10 2004
@@ -872,7 +872,7 @@
 		if (!buffer_uptodate(bh)) {
 			/* read error, skip block & hope for the best */
 			ext3_error(sb, __FUNCTION__, "reading directory #%lu "
-				   "offset %lu\n", dir->i_ino, block);
+				   "offset %lu", dir->i_ino, block);
 			brelse(bh);
 			goto next;
 		}

Re: [path 2.6] reduce ext3 log spamming (blank lines)

[Andrew Morton]

David Brownell <david-b@pacbell.net> wrote:
>
> When drives go offline, e.g. usb-storage disconnect, the
> upper layers don't behave very intelligently yet:  ext3
> over scsi keeps retrying reads, logging three lines for
> each error:
> 
> 10:58:31  scsi0 (0:0): rejecting I/O to dead device
> 10:58:31  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
> 10:58:31  
> 10:58:55  scsi0 (0:0): rejecting I/O to dead device
> ...
> This patch shrinks that log spam by the trivial third, getting
> rid of those needless blank lines.

Thanks.

>  It's not clear to me why
> the "no such device" errors don't immediately make ext3
> (or is it the block layer?) give up ... maybe someone else
> can make Linux not retry after those errors.

It's probably ext3 directory readahead.

We deliberately ignore I/O error when reading directories so that if you
have a bad block in a directory it is still possible to recover files which
are addressed by later blocks.