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@xxxxxxxxxx <mailto:ovasik@xxxxxxxxxx>> 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@xxxxxxxxxx>
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@xxxxxxxxxx>
Acked-by: "Theodore Ts'o" <tytso@xxxxxxx>
Signed-off-by: Jan Kara <jack@xxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
