[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AB25B61.6050201@it-sudparis.eu>
Date: Thu, 17 Sep 2009 17:53:05 +0200
From: jehan procaccia <jehan.procaccia@...sudparis.eu>
To: linux-ext4@...r.kernel.org
CC: Eric Sandeen <sandeen@...hat.com>
Subject: Re: ext4 and quota generate "Data will be lost" errors :-(
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@...hat.com <mailto:ovasik@...hat.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@...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@...ibm.com>
> Acked-by: "Theodore Ts'o" <tytso@....edu>
> Signed-off-by: Jan Kara <jack@...e.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists