lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 28 Apr 2009 09:36:55 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 13201] New: kernel BUG at fs/ext4/extents.c:2737

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@...nel-bugs.osdl.org
        ReportedBy: franco@...ro-fsi.com.au
        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.

--- Comment #1 from Franco Broi <franco@...ro-fsi.com.au>  2009-04-28 09:36:55 ---
Created an attachment (id=21153)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=21153)
messages file.

messages file for previous post.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ