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

[Eric Sandeen <sandeen@redhat.com>]

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