Any update on this?

Perhaps this might be related? It seems to fix things in FC12:

https://bugzilla.redhat.com/show_bug.cgi?id=521914

2 years to fix a bug? What's up, Redhat?

CentOS is not a Red Hat supported product. Please reproduce on a supported version of Red Hat linux with a supported file system (ext4 was only a tech preview item before RHEL5.7).

If you can reproduce on fedora or on an upstream kernel, that would also be interesting.

Thanks!

I am using ext4 and RHRL5.7, a supported configuration, and can reproduce this issue.  In fact, I have been seeing this ever since converting to ext4 when 5.7 first became available.  I resorted to disabling all warnings with dmesg -n 4 on startup, but of course now I am worried about missing something important.

# dmesg

[snip]

WARNING: at fs/dquot.c:814 dquot_claim_reserved_space()

Call Trace:
 [<ffffffff80106365>] dquot_claim_space+0xa3/0x110
 [<ffffffff8805a00b>] :ext4:ext4_da_update_reserve_space+0x12e/0x195
 [<ffffffff8806f2bc>] :ext4:ext4_ext_get_blocks+0x14f9/0x167d
 [<ffffffff8014685d>] elv_merged_request+0x1e/0x26
 [<ffffffff8000c201>] __make_request+0x3e3/0x4ce
 [<ffffffff80019e3e>] __getblk+0x25/0x22c
 [<ffffffff8805a18d>] :ext4:ext4_get_blocks+0x11b/0x1cf
 [<ffffffff8805a351>] :ext4:mpage_da_map_blocks+0xb0/0x678
 [<ffffffff80047cae>] pagevec_lookup_tag+0x1a/0x21
 [<ffffffff800f6c9e>] write_cache_pages+0x164/0x334
 [<ffffffff8805c382>] :ext4:__mpage_da_writepage+0x0/0x167
 [<ffffffff80047c8b>] __pagevec_release+0x19/0x22
 [<ffffffff800de6ce>] alternate_node_alloc+0x70/0x8c
 [<ffffffff8805dbf5>] :ext4:ext4_da_writepages+0x338/0x4ff
 [<ffffffff8005a8a6>] do_writepages+0x20/0x2f
 [<ffffffff8002fa24>] __writeback_single_inode+0x1a2/0x31c
 [<ffffffff80021143>] sync_sb_inodes+0x1b7/0x271
 [<ffffffff800a2c45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff80050ce2>] writeback_inodes+0x82/0xd8
 [<ffffffff800cc364>] wb_kupdate+0xd4/0x14e
 [<ffffffff800562a9>] pdflush+0x0/0x1fb
 [<ffffffff800563fa>] pdflush+0x151/0x1fb
 [<ffffffff800cc290>] wb_kupdate+0x0/0x14e
 [<ffffffff80032722>] kthread+0xfe/0x132
 [<ffffffff8009f868>] request_module+0x0/0x14d
 [<ffffffff8005dfb1>] child_rip+0xa/0x11
 [<ffffffff800a2c45>] keventd_create_kthread+0x0/0xc4
 [<ffffffff80032624>] kthread+0x0/0x132
 [<ffffffff8005dfa7>] child_rip+0x0/0x11

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.7 (Tikanga)

# uname -a
Linux clarus.cdeducation.org 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

# rpm -q quota
quota-3.13-5.el5

# mount |grep ext4
/dev/sda2 on / type ext4 (rw,noatime,usrjquota=aquota.user,jqfmt=vfsv0)

One time I did not mount the root filesystem with noatime, and I did not receive the warnings.  Therefore, I believe it is the combination of ext4, quota, and noatime that is triggering these.  Journaling the quota file does not have an effect.

-S

Thanks - opening a support ticket would also be helpful for tracking purposes.


The warning is:

dquot_claim_reserved_space() {
        WARN_ON(dquot->dq_dqb.dqb_rsvspace < number);

which basically means we've asked to claim more space than we have actually reserved.

Do you have any idea how to reproduce this?

The noatime thing -seems- like a red herring, since (no)atime should be unrelated to quota usage, and we have relatime on by default in any case, but perhaps, since both reporters had that option... 

0a5a9c725512461d19397490f3adf29931dca1f2 quota: Fix warning when a delayed
write happens before quota is enabled 
and
c469070aea5a0ada45a836937c776fd3083dae2b quota: manage reserved space when
quota is not active [v2]

may in fact fix it up.  I'll have to make sure they are quota-KABI safe.

(how did you get ext4 on a root filesystem?  AFAIK RHEL5 anaconda does not support that, so RHEL5 support status is probably not really there either.  That probably explains the message (IO on root happening before quota is enabled) and also explains why this hasn't been reported before (root ext4 on RHEL5 shouldn't really be possible, IIRC.)

(In reply to comment #8)
> (how did you get ext4 on a root filesystem?  AFAIK RHEL5 anaconda does not
> support that, so RHEL5 support status is probably not really there either. 
> That probably explains the message (IO on root happening before quota is
> enabled) and also explains why this hasn't been reported before (root ext4 on
> RHEL5 shouldn't really be possible, IIRC.)

root ext4 is very easy to create with a ks file.  You should also be able to create ext4 in anaconda if you pass ext4 on the boot line.

Ok, I thought that was disabled, apparently not ...

I don't seem to have to do anything special to reproduce it; the warnings just
start to kick in as soon as the system starts.

The system began life with RHEL 5.0, so every filesystem including root was
formatted ext3 initially.  The upgrade to 5.7 was done via RHN not anaconda. 
The filesystem was converted to ext4 by using tune4fs to enable extents, etc.
(tune4fs -O extents,uninit_bg) followed by a manual fsck.  I have not seen any
documentation that states that ext4 is not allowed on the root filesystem?

-S

You may be right about anaconda allowing it.  However, we don't support ext3->ext4 migrations, although for a while some docs implied that we did.

(you lose a LOT of the ext4 advantages when you migrate, vs. fresh mkfs)

Well, anyway.

I would appreciate it if you could file a support ticket for this.  The 2 commits above probably take care of it.

Thanks,
-Eric

Just to second Eric, migrating in place is not supported by Red Hat or recommended. Much better just to stay on ext3 for your file system that you cannot migrate and save ext4 for the newly formatted ones.

I can confirm that the issue seems to be resolved with the update to release 5.8.  Thank you.

Ok, based on comment #14, closing.  Thanks for the followup.

I just noticed that I have the same problem (probably) and it is *not* fixed in 5.8.

- Fully updated 5.8 (as of today)
- uname -a
Linux xxx.yyyy.se 2.6.18-308.4.1.el5 #1 SMP Wed Mar 28 01:54:56 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
- Newly created 2TB ext4 fs (ie not converted from ext3)
- mount output
 /dev/mapper/stud1 on /home/stud1 type ext4 (rw,_netdev,usrquota,nobarrier)

(The device is a Compellent SAN volume accessed over multipath/iSCSI if this is relevant)

- removed the "noatime" and umount+mount (as of comments above)

- Large amount of errors in /var/log/messages

Apr 27 12:31:02 empok kernel: WARNING: at fs/dquot.c:814 dquot_claim_reserved_space()
Apr 27 12:31:02 empok kernel:
Apr 27 12:31:02 empok kernel: Call Trace:
Apr 27 12:31:02 empok kernel:  [<ffffffff801079bb>] dquot_claim_space+0xa3/0x110
Apr 27 12:31:02 empok kernel:  [<ffffffff88a8a2af>] :ext4:ext4_da_update_reserve_space+0x12f/0x196
Apr 27 12:31:02 empok kernel:  [<ffffffff88a9f4a8>] :ext4:ext4_ext_get_blocks+0x14e1/0x1665
Apr 27 12:31:02 empok kernel:  [<ffffffff882769a4>] :dm_mod:dm_request+0x11d/0x124
Apr 27 12:31:02 empok kernel:  [<ffffffff8001c305>] generic_make_request+0x211/0x228
Apr 27 12:31:02 empok kernel:  [<ffffffff80023301>] mempool_alloc+0x31/0xe7
Apr 27 12:31:02 empok kernel:  [<ffffffff8003309a>] submit_bio+0xe6/0xed
Apr 27 12:31:02 empok kernel:  [<ffffffff88a8a431>] :ext4:ext4_get_blocks+0x11b/0x1cf
Apr 27 12:31:02 empok kernel:  [<ffffffff88a8a5f4>] :ext4:mpage_da_map_and_submit+0xb0/0x791
Apr 27 12:31:02 empok kernel:  [<ffffffff80047c5e>] pagevec_lookup_tag+0x1a/0x21
Apr 27 12:31:02 empok kernel:  [<ffffffff800f7ce9>] write_cache_pages+0x164/0x334
Apr 27 12:31:02 empok kernel:  [<ffffffff88a8c88d>] :ext4:__mpage_da_writepage+0x0/0x154
Apr 27 12:31:02 empok kernel:  [<ffffffff88a8ddee>] :ext4:ext4_da_writepages+0x353/0x4f8
Apr 27 12:31:02 empok kernel:  [<ffffffff8005a8a3>] do_writepages+0x20/0x2f
Apr 27 12:31:02 empok kernel:  [<ffffffff8002f915>] __writeback_single_inode+0x1a2/0x31c
Apr 27 12:31:02 empok kernel:  [<ffffffff80020ff6>] sync_sb_inodes+0x1b7/0x271
Apr 27 12:31:02 empok kernel:  [<ffffffff800a328f>] keventd_create_kthread+0x0/0xc4
Apr 27 12:31:02 empok kernel:  [<ffffffff80050ce0>] writeback_inodes+0x82/0xd8
Apr 27 12:31:02 empok kernel:  [<ffffffff800ccefc>] wb_kupdate+0xf0/0x16a
Apr 27 12:31:02 empok kernel:  [<ffffffff8005626f>] pdflush+0x0/0x1fb
Apr 27 12:31:02 empok kernel:  [<ffffffff800563c0>] pdflush+0x151/0x1fb
Apr 27 12:31:02 empok kernel:  [<ffffffff800cce0c>] wb_kupdate+0x0/0x16a
Apr 27 12:31:02 empok kernel:  [<ffffffff80032632>] kthread+0xfe/0x132
Apr 27 12:31:02 empok kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Apr 27 12:31:02 empok kernel:  [<ffffffff800a328f>] keventd_create_kthread+0x0/0xc4
Apr 27 12:31:02 empok kernel:  [<ffffffff80032534>] kthread+0x0/0x132
Apr 27 12:31:02 empok kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11

Magnus, ok, we need a new bug then.  It'd also be great if you logged a support ticket.

Thanks,
-Eric