ext4 and quota generate "Data will be lost" errors :-(

ext4 and quota generate "Data will be lost" errors :-(

[jehan procaccia]

Since I run a ext4 FS with quota on my Redhat 5.4 , I often get these 
kind of messages on the console:

Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
gizeh kernel: mpage_da_map_blocks block allocation failed for inode 
3412191 at logical offset 0 with max blocks 1 with error -122
Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
gizeh kernel: This should not happen.!! Data will be lost

my system is runing on:
$ 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 
I upgraded redhat quota package from recompile fedora10 sources because 
of this changelog:

* Thu Oct 30 2008 Ondrej Vasik <ovasik@redhat.com <mailto:ovasik@redhat.com>> 1:3.16-6
- fix implementation of ext4 support


I have a discussion with redhat on this: 
https://bugzilla.redhat.com/show_bug.cgi?id=522615
the reponse is to move back to ext3 until redhat support quota for ext4 .

my probleme is that I have lot of users and filesystems in this 
situation now, and I wonder I couldn't expect a workaround ?
is this issue know in recent kernel,  will I really lose data ? 
any advice greatly appreciated .

regards

Re: ext4 and quota generate "Data will be lost" errors :-(

[Eric Sandeen]

jehan procaccia wrote:
> Since I run a ext4 FS with quota on my Redhat 5.4 , I often get these 
> kind of messages on the console:
> 
> Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
> gizeh kernel: mpage_da_map_blocks block allocation failed for inode 
> 3412191 at logical offset 0 with max blocks 1 with error -122
> Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
> gizeh kernel: This should not happen.!! Data will be lost
> 
> my system is runing on:
> $ 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

which has a 2.6.29-ish ext4 codebase

> $ rpm -q quota
> quota-3.16-7 
> I upgraded redhat quota package from recompile fedora10 sources because 
> of this changelog:
> 
> * Thu Oct 30 2008 Ondrej Vasik <ovasik@redhat.com <mailto:ovasik@redhat.com>> 1:3.16-6
> - fix implementation of ext4 support

and this will not affect your kernelspace issues, which were mostly
fixed in .30 by this and other commits:

commit 60e58e0f30e723464c2a7d34b71b8675566c572d
Author: Mingming Cao <cmm@us.ibm.com>
Date:   Thu Jan 22 18:13:05 2009 +0100

    ext4: quota reservation for delayed allocation

    Uses quota reservation/claim/release to handle quota properly for
delayed
    allocation in the three steps: 1) quotas are reserved when data
being copied
    to cache when block allocation is defered 2) when new blocks are
allocated.
    reserved quotas are converted to the real allocated quota, 2)
over-booked
    quotas for metadata blocks are released back.

    Signed-off-by: Mingming Cao <cmm@us.ibm.com>
    Acked-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Jan Kara <jack@suse.cz>

> I have a discussion with redhat on this: 
> https://bugzilla.redhat.com/show_bug.cgi?id=522615
> the reponse is to move back to ext3 until redhat support quota for ext4 .
> 
> my probleme is that I have lot of users and filesystems in this 
> situation now, and I wonder I couldn't expect a workaround ?
> is this issue know in recent kernel,  will I really lose data ? 
> any advice greatly appreciated .

It's a fundamental change in quota to deal with delalloc, which was not
ready in time for RHEL5.4.  It's mostly fixed upstream, though there
have been some recent bug reports.  If anyone on the list has other
suggestions I'm all ears, but I think we've covered most of this in the
bug already.

Thanks,
-Eric

Re: ext4 and quota generate "Data will be lost" errors :-(

[jehan procaccia]

Eric Sandeen a écrit :
> jehan procaccia wrote:
>> $ rpm -q quota
>> quota-3.16-7 
>> I upgraded redhat quota package from recompile fedora10 sources because 
>> of this changelog:
>>
>> * Thu Oct 30 2008 Ondrej Vasik <ovasik@redhat.com <mailto:ovasik@redhat.com>> 1:3.16-6
>> - fix implementation of ext4 support
>>     
>
> and this will not affect your kernelspace issues, which were mostly
> fixed in .30 by this and other commits:
>
> commit 60e58e0f30e723464c2a7d34b71b8675566c572d
> Author: Mingming Cao <cmm@us.ibm.com>
> Date:   Thu Jan 22 18:13:05 2009 +0100
>
>     ext4: quota reservation for delayed allocation
>
>     Uses quota reservation/claim/release to handle quota properly for
> delayed
>     allocation in the three steps: 1) quotas are reserved when data
> being copied
>     to cache when block allocation is defered 2) when new blocks are
> allocated.
>     reserved quotas are converted to the real allocated quota, 2)
> over-booked
>     quotas for metadata blocks are released back.
>
>     Signed-off-by: Mingming Cao <cmm@us.ibm.com>
>     Acked-by: "Theodore Ts'o" <tytso@mit.edu>
>     Signed-off-by: Jan Kara <jack@suse.cz>
>
>   
Then I suppose it will be solved for me when redhat will ship a 2.6.30 
kernel ?
is there such kernel backport to an rpm for redhat 5.4, or maybe a 
rawhide one that I could recompile for rhel 5.4 ?
if  kernel 2.6.18-164.el5 is in real a 2.6.29 codebase, how can we 
translate redhat rpm kernel version number  to real kernel version number ?
>> I have a discussion with redhat on this: 
>> https://bugzilla.redhat.com/show_bug.cgi?id=522615
>> the reponse is to move back to ext3 until redhat support quota for ext4 .
>>
>> my probleme is that I have lot of users and filesystems in this 
>> situation now, and I wonder I couldn't expect a workaround ?
>> is this issue know in recent kernel,  will I really lose data ? 
>> any advice greatly appreciated .
>>     
>
> It's a fundamental change in quota to deal with delalloc, which was not
> ready in time for RHEL5.4.  It's mostly fixed upstream, though there
> have been some recent bug reports.  If anyone on the list has other
> suggestions I'm all ears, but I think we've covered most of this in the
> bug already.
>
>   

Yes any suggestions from this list  ? I'am all ears too ...

Am I actually really "losing" data ?

Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
> gizeh kernel: mpage_da_map_blocks block allocation failed for inode 
> 3412191 at logical offset 0 with max blocks 1 with error -122
> Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
> gizeh kernel: This should not happen.!! Data will be lost


thanks Eric for responding on all media ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ext4 and quota generate "Data will be lost" errors :-(

[Eric Sandeen]

jehan procaccia wrote:
> Eric Sandeen a écrit :
>> jehan procaccia wrote:
>>> $ rpm -q quota
>>> quota-3.16-7 
>>> I upgraded redhat quota package from recompile fedora10 sources because 
>>> of this changelog:
>>>
>>> * Thu Oct 30 2008 Ondrej Vasik <ovasik@redhat.com <mailto:ovasik@redhat.com>> 1:3.16-6
>>> - fix implementation of ext4 support
>>>     
>> and this will not affect your kernelspace issues, which were mostly
>> fixed in .30 by this and other commits:
>>
>> commit 60e58e0f30e723464c2a7d34b71b8675566c572d
>> Author: Mingming Cao <cmm@us.ibm.com>
>> Date:   Thu Jan 22 18:13:05 2009 +0100
>>
>>     ext4: quota reservation for delayed allocation
>>
>>     Uses quota reservation/claim/release to handle quota properly for
>> delayed
>>     allocation in the three steps: 1) quotas are reserved when data
>> being copied
>>     to cache when block allocation is defered 2) when new blocks are
>> allocated.
>>     reserved quotas are converted to the real allocated quota, 2)
>> over-booked
>>     quotas for metadata blocks are released back.
>>
>>     Signed-off-by: Mingming Cao <cmm@us.ibm.com>
>>     Acked-by: "Theodore Ts'o" <tytso@mit.edu>
>>     Signed-off-by: Jan Kara <jack@suse.cz>
>>
>>   
> Then I suppose it will be solved for me when redhat will ship a 2.6.30 
> kernel ?

Or when/if quota fixes are backported to RHEL5.4.  I'd suggest talking
to your RHEL support people about this; the upstream devel forum is
unfortunately probably not the best place to resolve distro kernel issues.

> is there such kernel backport to an rpm for redhat 5.4, or maybe a 
> rawhide one that I could recompile for rhel 5.4 ?

All this would be well outside any supported configuration, of course...

> if  kernel 2.6.18-164.el5 is in real a 2.6.29 codebase, how can we 
> translate redhat rpm kernel version number  to real kernel version number ?

Distribution kernels are almost always an older branch point + a lot of
subsequent patches for features & bugs.

In the case of ext4, you can look at the kernel changelog and find:

- [fs] rebase ext4 and jbd2 to 2.6.29 codebase (Eric Sandeen)

>>> I have a discussion with redhat on this: 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=522615
>>> the reponse is to move back to ext3 until redhat support quota for ext4 .
>>>
>>> my probleme is that I have lot of users and filesystems in this 
>>> situation now, and I wonder I couldn't expect a workaround ?
>>> is this issue know in recent kernel,  will I really lose data ? 
>>> any advice greatly appreciated .
>>>     
>> It's a fundamental change in quota to deal with delalloc, which was not
>> ready in time for RHEL5.4.  It's mostly fixed upstream, though there
>> have been some recent bug reports.  If anyone on the list has other
>> suggestions I'm all ears, but I think we've covered most of this in the
>> bug already.
>>
>>   
> 
> Yes any suggestions from this list  ? I'am all ears too ...
> 
> Am I actually really "losing" data ?

Most likely yes...

> Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
>> gizeh kernel: mpage_da_map_blocks block allocation failed for inode 
>> 3412191 at logical offset 0 with max blocks 1 with error -122
>> Message from syslogd@ at Thu Sep 17 15:40:11 2009 ...
>> gizeh kernel: This should not happen.!! Data will be lost
> 
> 
> thanks Eric for responding on all media ;-)

It's my job ;)  Sorry to give you the same answer everywhere!

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html