Skip to contentSkip to conversation

New: cascade of "mpage_da_map_blocks block allocation failed" errors

Bug 13604 [email protected] 1 participant 5 messages Jun 22, 2009 – Mar 15, 2010

lore
Share & tools
lore
#0 lore raw

http://bugzilla.kernel.org/show_bug.cgi?id=13604

Summary: cascade of "mpage_da_map_blocks block allocation
failed" errors
Product: File System
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

While qemu was writing on a qcow2 image -- presumably a sparse, mmaped() file --
the home partition filled up to the reserved block limit, and the kernel started issuing a cascade of errors, making the system very unresponsive for 30 seconds.

Eventually, the qemu process was killed with a SIGSEGV, but the system was still unusable because every process attempting to read/write on /home would lockup in an uninterruptable sleep state.

This is kernel-2.6.30-1.fc12.x86_64.

---cut---

Jun 22 20:49:03 localhost kernel: mpage_da_map_blocks block allocation failed
for inode 528965 at logical offset 607602 with max blocks 5 with error -28
Jun 22 20:49:03 localhost kernel: This should not happen.!! Data will be lost
Jun 22 20:49:03 localhost kernel: Total free blocks count 0
Jun 22 20:49:03 localhost kernel: Free/Dirty block details
Jun 22 20:49:03 localhost kernel: free_blocks=134303
Jun 22 20:49:03 localhost kernel: dirty_blocks=52621
Jun 22 20:49:03 localhost kernel: Block reservation details
Jun 22 20:49:03 localhost kernel: i_reserved_data_blocks=52465
Jun 22 20:49:03 localhost kernel: i_reserved_meta_blocks=156
Jun 22 20:49:03 localhost kernel: mpage_da_map_blocks block allocation failed
for inode 528965 at logical offset 608030 with max blocks 8 with error -28
Jun 22 20:49:03 localhost kernel: This should not happen.!! Data will be lost
Jun 22 20:49:03 localhost kernel: Total free blocks count 0
Jun 22 20:49:03 localhost kernel: Free/Dirty block details
Jun 22 20:49:03 localhost kernel: free_blocks=134303
Jun 22 20:49:03 localhost kernel: dirty_blocks=52621
Jun 22 20:49:03 localhost kernel: Block reservation details
Jun 22 20:49:03 localhost kernel: i_reserved_data_blocks=52465
Jun 22 20:49:03 localhost kernel: i_reserved_meta_blocks=156
Jun 22 20:49:09 localhost kernel: mpage_da_map_blocks block allocation failed
for inode 125287 at logical offset 4 with max blocks 1 with error -28
Jun 22 20:49:09 localhost kernel: This should not happen.!! Data will be lost
Jun 22 20:49:09 localhost kernel: Total free blocks count 0
Jun 22 20:49:09 localhost kernel: Free/Dirty block details
Jun 22 20:49:09 localhost kernel: free_blocks=134303
Jun 22 20:49:09 localhost kernel: dirty_blocks=52624
Jun 22 20:49:09 localhost kernel: Block reservation details
Jun 22 20:49:09 localhost kernel: i_reserved_data_blocks=1
Jun 22 20:49:09 localhost kernel: i_reserved_meta_blocks=2
Jun 22 20:52:36 localhost libvirtd: 20:52:36.573: warning :

qemudDispatchSignalEvent:362 : Shutting down on signal 15 ---cut---

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#1 lore raw

[Bug 13604] cascade of "mpage_da_map_blocks block allocation failed" errors

http://bugzilla.kernel.org/show_bug.cgi?id=13604

Cyber <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Cyber <[email protected]> 2009-08-11 11:00:31 --- Hello! (:

same problem here with kernel 2.6.30.4.

my partition was filled completly.
my partition table is correct, all partitions were never resized, they were created new with ext4 (not migrated from ext3).

[941998.471199] mpage_da_map_blocks block allocation failed for inode 36 at
logical offset 3544 with max blocks 1 with error -28
[941998.471345] This should not happen.!! Data will be lost
[941998.471444] Total free blocks count 0
[941998.471524] Free/Dirty block details
[941998.471603] free_blocks=0
[941998.471680] dirty_blocks=0
[941998.471757] Block reservation details
[941998.471838] i_reserved_data_blocks=2
[941998.471918] i_reserved_meta_blocks=2
[941998.472638] mpage_da_map_blocks block allocation failed for inode 36 at
logical offset 3865 with max blocks 1 with error -28
[941998.472799] This should not happen.!! Data will be lost
[941998.472898] Total free blocks count 0
[941998.472978] Free/Dirty block details
[941998.473058] free_blocks=0
[941998.473135] dirty_blocks=0
[941998.473213] Block reservation details
[941998.473294] i_reserved_data_blocks=2
[941998.473374] i_reserved_meta_blocks=2
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#2 lore raw

[Bug 13604] cascade of "mpage_da_map_blocks block allocation failed" errors

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=13604

procaccia <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |jehan.procaccia@it-sudparis
                   |                            |.eu

--- Comment #2 from procaccia <[email protected]> 2009-09-17 14:44:42 --- Any news on this bug ?

I get lots of the same error messages with ext4 and quotas on those ext4 FS:

Message from syslogd@ at Thu Sep 17 16:39:51 2009 ...
gizeh kernel: mpage_da_map_blocks block allocation failed for inode 15407 at logical offset 0 with max blocks 2 with error -122
Message from syslogd@ at Thu Sep 17 16:39:51 2009 ...
gizeh kernel: This should not happen.!! Data will be lost

$ uname -a
Linux gizeh.int-evry.fr 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q quota
quota-3.16-7

Will data really be lost ? or is this alert is for people over-quota only ? I have opened a bug on redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=522615
I've been told to wait until kernel quota for ext4 will be supported, but what is the probleme ? is there a plan to solve this issue ? perhaps it's already solve on a newer kernel than mine (2.6.18-164.el5 ) ?
Any news & advice greatly appreciated.
regards .

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#3 lore raw

[Bug 13604] cascade of "mpage_da_map_blocks block allocation failed" errors

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=13604

Eric Sandeen <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #3 from Eric Sandeen <[email protected]> 2009-09-17 15:51:13 ---
re: comment #3 It's the same end result, delalloc data with nowhere to go.

But the first 2 filers were hitting errno -28 == ENOSPC, where ext4 oversubscribed delayed allocation. I think this is still a corner case bug upstream, but better than it was.

comment #3 is an older ext4 codebase hitting quota problems (-122 == EDQUOT) which should be fixed upstream now.

-Eric

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#4 lore raw

[Bug 13604] cascade of "mpage_da_map_blocks block allocation failed" errors

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=13604

Eric Sandeen <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         AssignedTo|[email protected] |[email protected]
                   |g                           |
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.