http://bugzilla.kernel.org/show_bug.cgi?id=13201 Summary: kernel BUG at fs/ext4/extents.c:2737 Product: File System Version: 2.5 Kernel Version: 2.6.29.1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: ext4 AssignedTo: fs_ext4@xxxxxxxxxxxxxxxxxxxx ReportedBy: franco@xxxxxxxxxxxxxxxx Regression: No I got this while testing ext4 on an external RAID system. The system has 4 identical RAID systems each with a single 13TB filesystem. Only one of the 4 failed the test which was to simply write 8GB files until the disk fills up. The complete messages file is attached. Apr 25 01:59:38 echo19 kernel: EXT4-fs error (device dm-2): __ext4_get_inode_loc: unable to read inode block - inode=761860, block=3612686232 Apr 25 01:59:38 echo19 kernel: EXT4-fs error (device dm-2) in ext4_reserve_inode_write: IO failure Apr 25 01:59:38 echo19 kernel: mpage_da_map_blocks block allocation failed for inode 761860 at logical offset 699276 with max blocks 1024 with error -5 Apr 25 01:59:38 echo19 kernel: This should not happen.!! Data will be lost Apr 25 01:59:38 echo19 kernel: ------------[ cut here ]------------ Apr 25 01:59:38 echo19 kernel: kernel BUG at fs/ext4/extents.c:2737! The filesystem was totally inaccessible so I reset the system. On reboot, the filesystem couldn't be mounted - bad superblock. I ran fsck a few times before I could remount the filesystem, all the directories were lost but the test files were intact in lost+found. I can't see any errors anywhere that might indicate that this is a hardware problem but these are brand new systems using SAS host connections which we haven't used before. I've remade the broken filesystem and restarted the test on this and 11 other identical filesystems, I'll let you know if the problem reoccurs. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
