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

[jehan procaccia <jehan.procaccia@it-sudparis.eu>]

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