JFS error "dbAlloc: the hint is outside the map"
Posted 05-06-2012 at 05:10 AM by catkin
This error seems to be rare. Netsearching for "the hint is outside the map" found only source code repositories and a message database with no information beyond the message itself. No pages were found reporting the message occurring in the wild.
The original patch which introduced the message (http://permalink.gmane.org/gmane.com...jfs.patches/49) has this comment:
The message appeared in /var/log/syslog on a Debian Squeeze system which was showing no other signs of on-disk data corruption and no unusual smartmon messages.
It may have been triggered by resizing the file system which is on an LVM LV. The resize was done at ~16:30. The error message was at 00:14 the next day.
The system has had problems re-sizing another JFS (also on an LVM LV on the same HDD) twice before, as reported at https://bugzilla.kernel.org/show_bug.cgi?id=14979
The original patch which introduced the message (http://permalink.gmane.org/gmane.com...jfs.patches/49) has this comment:
Quote:
# 03/10/14 shaggy <at> shaggy.austin.ibm.com 1.1155
# JFS: Improved error handing
#
# This patch replaces many assert statements, which caused a BUG(), with
# improved code to mark the superblock dirty and then proceed as specified by
# the errors= mount flag (as ext2 and ext3 do). JFS's default for the errors
# option is "remount-ro" in order to prevent addition data corruption when a
# problem is found.
#
# These asserts are usually triggered by on-disk data corruption. By marking
# the superblock dirty, fsck will perform a complete check on the file system
# and correct the problems, rather than simply replaying the journal, inviting
# later trouble.
# JFS: Improved error handing
#
# This patch replaces many assert statements, which caused a BUG(), with
# improved code to mark the superblock dirty and then proceed as specified by
# the errors= mount flag (as ext2 and ext3 do). JFS's default for the errors
# option is "remount-ro" in order to prevent addition data corruption when a
# problem is found.
#
# These asserts are usually triggered by on-disk data corruption. By marking
# the superblock dirty, fsck will perform a complete check on the file system
# and correct the problems, rather than simply replaying the journal, inviting
# later trouble.
It may have been triggered by resizing the file system which is on an LVM LV. The resize was done at ~16:30. The error message was at 00:14 the next day.
The system has had problems re-sizing another JFS (also on an LVM LV on the same HDD) twice before, as reported at https://bugzilla.kernel.org/show_bug.cgi?id=14979
Total Comments 0
