aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ext3
diff options
context:
space:
mode:
authorStephen Tweedie <sct@redhat.com>2005-05-18 11:47:17 -0400
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-05-18 12:10:02 -0400
commit301216244b1e39c4346e56d38b079ca53d528580 (patch)
tree4a16a1f4cf249d713e565c1b2113ca3b38d3ba45 /fs/ext3
parente72022e13d659bece2fc9cb2dd97afa67047dbca (diff)
[PATCH] Avoid console spam with ext3 aborted journal.
Avoid console spam with ext3 aborted journal. ext3 usually reports error conditions that it detects in its environment. But when its journal gets aborted due to such errors, it can sometimes continue to report that condition forever, spamming the console to such an extent that the initial first cause of the journal abort can be lost. When the journal aborts, we put the filesystem into readonly mode. Most subsequent filesystem operations will get rejected immediately by checks for MS_RDONLY either in the filesystem or in the VFS. But some paths do not have such checks --- for example, if we continue to write to a file handle that was opened before the fs went readonly. (We only check for the ROFS condition when the file is first opened.) In these cases, we can continue to generate log errors similar to EXT3-fs error (device $DEV) in start_transaction: Journal has aborted for each subsequent write. There is really no point in generating these errors after the initial error has been fully reported. Specifically, if we're starting a completely new filesystem operation, and the filesystem is *already* readonly (ie. the ext3 layer has already detected and handled the underlying jbd abort), and we see an EROFS error, then there is simply no point in reporting it again. Signed-off-by: Stephen Tweedie <sct@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/ext3')
-rw-r--r--fs/ext3/super.c10
1 files changed, 9 insertions, 1 deletions
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 545b440a2d2f..981ccb233ef5 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -225,8 +225,16 @@ void __ext3_std_error (struct super_block * sb, const char * function,
225 int errno) 225 int errno)
226{ 226{
227 char nbuf[16]; 227 char nbuf[16];
228 const char *errstr = ext3_decode_error(sb, errno, nbuf); 228 const char *errstr;
229
230 /* Special case: if the error is EROFS, and we're not already
231 * inside a transaction, then there's really no point in logging
232 * an error. */
233 if (errno == -EROFS && journal_current_handle() == NULL &&
234 (sb->s_flags & MS_RDONLY))
235 return;
229 236
237 errstr = ext3_decode_error(sb, errno, nbuf);
230 printk (KERN_CRIT "EXT3-fs error (device %s) in %s: %s\n", 238 printk (KERN_CRIT "EXT3-fs error (device %s) in %s: %s\n",
231 sb->s_id, function, errstr); 239 sb->s_id, function, errstr);
232 240