summaryrefslogtreecommitdiffstats
path: root/fs/jbd2
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2010-07-27 11:56:08 -0400
committerTheodore Ts'o <tytso@mit.edu>2010-07-27 11:56:08 -0400
commite3570639c8b5f2c6a5018a2649c2b7c276af76d7 (patch)
tree07c497204ba370c5e64b5868aa704e269e5893a3 /fs/jbd2
parentd889dc8382c4d71b6d538b7b13777bc1ec51df10 (diff)
downloadblackbird-op-linux-e3570639c8b5f2c6a5018a2649c2b7c276af76d7.tar.gz
blackbird-op-linux-e3570639c8b5f2c6a5018a2649c2b7c276af76d7.zip
ext4: don't print scary messages for allocation failures post-abort
I often get emails containing the "This should not happen!!" message, conveniently trimmed to remove things like: sd 0:0:0:0: [sda] Unhandled error code sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 03 13 c9 70 00 00 28 00 end_request: I/O error, dev sda, sector 51628400 Aborting journal on device dm-0-8. EXT4-fs error (device dm-0): ext4_journal_start_sb: Detected aborted journal EXT4-fs (dm-0): Remounting filesystem read-only I don't think there is any value to the verbosity if the reason is due to a filesystem abort; it just obfuscates the root cause. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/jbd2')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud