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@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 ? 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
