static void dquot_claim_reserved_space(struct dquot *dquot,
                                                qsize_t number)
{
        WARN_ON(dquot->dq_dqb.dqb_rsvspace < number);
        dquot->dq_dqb.dqb_curspace += number;
        dquot->dq_dqb.dqb_rsvspace -= number;
}

The quota code hasn't changed, so I'd suspect and ext4 bug.

This is a new function made just for ext4:

740d9dcd	(Mingming Cao	2009-01-13 16:43:14 +0100	961)static void dquot_claim_reserved_space(struct dquot *dquot,

commit 740d9dcd949a986c88886a591054a0cdb89ef669
Author: Mingming Cao <cmm.com>
Date:   Tue Jan 13 16:43:14 2009 +0100

    quota: Add quota reservation claim and released operations

AFAIK ext4 quota wasn't really working at all prior to .30 so it's not really a regression, though it does look like a bug.  Guessing a locking problem around some bucket of usage information in quota and/or ext4.

-Eric

Thank you for your help so far.

However, the strange part is that I do not have any quota limits for any of my users at this time. 

Please let me know if you need any more information.

Oh, well that is most unfortunate, if you didn't even have quota set.  :)

Do you have any quota on at all?  (maybe quotas enabled but no limits set?)

I'll see what's going on, thanks.

-Eric

Correct, the quota is enabled with "Unlimited". At this time I don't have any users that I am worried about taking up to much space.

Maybe I will create a user.. with a quota limit and see what happens? 

Thanks,
Derek

If you feel like testing, sure ;)

-Eric

Okay, I will do some testing on my side... I only knew how to adjust quota's via Webmin :(  .....

Normally when I would go to "Quota" usages, it would give me a long list of everyone on my system and how much space they are using. That does not happen anymore. If I select my username, it does not let me edit it anymore. I would think that is a Webmin issue, but I dont know. 

At this time I disabled the quota, I am going to see if I keep getting those error messages...

Thanks,

Upstream discussion:
http://marc.info/?t=125238694400002&r=1&w=2

(In reply to comment #7)
> Okay, I will do some testing on my side... I only knew how to adjust quota's
> via Webmin :(  .....
> 
> Normally when I would go to "Quota" usages, it would give me a long list of
> everyone on my system and how much space they are using. That does not happen
> anymore. If I select my username, it does not let me edit it anymore. I would
> think that is a Webmin issue, but I dont know. 
> 
> At this time I disabled the quota, I am going to see if I keep getting those
> error messages...
> 
> Thanks,  

The Error Message have stopped.. with Quota Disabled.

Same here for x86_64:

2009-09-10T14:20:01.928275+02:00 home07 kernel: ------------[ cut here ]------------
2009-09-10T14:20:01.928285+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xd9/0x14e() (Tainted: P        W )
2009-09-10T14:20:01.928292+02:00 home07 kernel: Hardware name: System Product Name
2009-09-10T14:20:01.928324+02:00 home07 kernel: Modules linked in: fuse bridge stp llc bnep sco l2cap bluetooth it87 hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath raid1 kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel ppdev snd_hda_codec snd_hwdep nvidia(P) snd_pcm snd_timer snd k8temp serio_raw pcspkr soundcore 8139too i2c_nforce2 snd_page_alloc parport_pc 8139cp hfcpci asus_atk0110 mISDN_core forcedeth mii parport hwmon i2c_core joydev pata_amd ata_generic pata_acpi sata_nv raid456 raid6_pq async_xor async_memcpy async_tx xor [last unloaded: scsi_wait_scan]
2009-09-10T14:20:01.928337+02:00 home07 kernel: Pid: 29, comm: pdflush Tainted: P        W  2.6.30.5-43.fc11.x86_64 #1
2009-09-10T14:20:01.928343+02:00 home07 kernel: Call Trace:
2009-09-10T14:20:01.928351+02:00 home07 kernel: [<ffffffff81057104>] warn_slowpath_common+0x95/0xc3
2009-09-10T14:20:01.928359+02:00 home07 kernel: [<ffffffff81057159>] warn_slowpath_null+0x27/0x3d
2009-09-10T14:20:01.928368+02:00 home07 kernel: [<ffffffff81160b7f>] dquot_claim_space+0xd9/0x14e
2009-09-10T14:20:01.928376+02:00 home07 kernel: [<ffffffff811af275>] ext4_mb_mark_diskspace_used+0x332/0x3f0
2009-09-10T14:20:01.928385+02:00 home07 kernel: [<ffffffff811b2beb>] ext4_mb_new_blocks+0x243/0x4bc
2009-09-10T14:20:01.928394+02:00 home07 kernel: [<ffffffff811a87bf>] ? ext4_ext_find_extent+0x62/0x29c
2009-09-10T14:20:01.928402+02:00 home07 kernel: [<ffffffff811aa5ae>] ext4_ext_get_blocks+0xb69/0xd3b
2009-09-10T14:20:01.928410+02:00 home07 kernel: [<ffffffff812104d8>] ? generic_make_request+0x254/0x2b2
2009-09-10T14:20:01.928418+02:00 home07 kernel: [<ffffffff81197ca4>] ext4_get_blocks_wrap+0x117/0x271
2009-09-10T14:20:01.928427+02:00 home07 kernel: [<ffffffff81199326>] mpage_da_map_blocks+0xc0/0x5fa
2009-09-10T14:20:01.928434+02:00 home07 kernel: [<ffffffff810dd200>] ? pagevec_lookup_tag+0x34/0x54
2009-09-10T14:20:01.928442+02:00 home07 kernel: [<ffffffff810db207>] ? write_cache_pages+0x195/0x40c
2009-09-10T14:20:01.928450+02:00 home07 kernel: [<ffffffff811bfce9>] ? jbd2_journal_start+0xb7/0x106
2009-09-10T14:20:01.928459+02:00 home07 kernel: [<ffffffff81199b9d>] ext4_da_writepages+0x33d/0x53a
2009-09-10T14:20:01.928467+02:00 home07 kernel: [<ffffffff810db503>] do_writepages+0x3a/0x60
2009-09-10T14:20:01.928476+02:00 home07 kernel: [<ffffffff811345b4>] __writeback_single_inode+0x168/0x2a8
2009-09-10T14:20:01.928542+02:00 home07 kernel: [<ffffffff81134b26>] generic_sync_sb_inodes+0x21a/0x361
2009-09-10T14:20:01.928550+02:00 home07 kernel: [<ffffffff81134ee3>] writeback_inodes+0xb0/0x119
2009-09-10T14:20:01.928558+02:00 home07 kernel: [<ffffffff810db73c>] wb_kupdate+0xc0/0x14a
2009-09-10T14:20:01.928566+02:00 home07 kernel: [<ffffffff810dc802>] pdflush+0x16d/0x272
2009-09-10T14:20:01.928574+02:00 home07 kernel: [<ffffffff810db67c>] ? wb_kupdate+0x0/0x14a
2009-09-10T14:20:01.928582+02:00 home07 kernel: [<ffffffff810dc695>] ? pdflush+0x0/0x272
2009-09-10T14:20:01.928590+02:00 home07 kernel: [<ffffffff81070665>] kthread+0x6d/0xae
2009-09-10T14:20:01.928597+02:00 home07 kernel: [<ffffffff8101313a>] child_rip+0xa/0x20
2009-09-10T14:20:01.928605+02:00 home07 kernel: [<ffffffff81012afd>] ? restore_args+0x0/0x30
2009-09-10T14:20:01.928613+02:00 home07 kernel: [<ffffffff810705f8>] ? kthread+0x0/0xae
2009-09-10T14:20:01.928621+02:00 home07 kernel: [<ffffffff81013130>] ? child_rip+0x0/0x20
2009-09-10T14:20:01.928628+02:00 home07 kernel: ---[ end trace 263effe0036f45d1 ]---

I know it's tainted because of the nvidia driver, but I think it's not relevant

Note: This has hit the top-ten list on kerneloops.org:

http://www.kerneloops.org/searchweek.php?search=dquot_claim_space

x86_64 again (2.6.30.9-90.fc11.x86_64)

WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xd9/0x14e() (Tainted: P        W )
Hardware name: System Product Name
Modules linked in: fuse bridge stp llc bnep sco l2cap bluetooth it87 hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath raid1 kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep ppdev snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm nvidia(P) snd_timer snd 8139too 8139cp hfcpci soundcore serio_raw i2c_nforce2 k8temp mISDN_core pata_amd parport_pc forcedeth parport asus_atk0110 mii pcspkr i2c_core joydev hwmon snd_page_alloc ata_generic pata_acpi sata_nv raid456 raid6_pq async_xor async_memcpy async_tx xor [last unloaded: scsi_wait_scan]
Pid: 29, comm: pdflush Tainted: P        W  2.6.30.9-90.fc11.x86_64 #1
Call Trace:
 [<ffffffff81057098>] warn_slowpath_common+0x95/0xc3
 [<ffffffff810570ed>] warn_slowpath_null+0x27/0x3d
 [<ffffffff8115ed03>] dquot_claim_space+0xd9/0x14e
 [<ffffffff811ad445>] ext4_mb_mark_diskspace_used+0x332/0x3f0
 [<ffffffff811b0dbd>] ext4_mb_new_blocks+0x243/0x4be
 [<ffffffff811a698f>] ? ext4_ext_find_extent+0x62/0x29c
 [<ffffffff811a877e>] ext4_ext_get_blocks+0xb69/0xd3b
 [<ffffffff8120e670>] ? generic_make_request+0x254/0x2b2
 [<ffffffff81195e74>] ext4_get_blocks_wrap+0x117/0x271
 [<ffffffff811974f6>] mpage_da_map_blocks+0xc0/0x5fa
 [<ffffffff810db94c>] ? pagevec_lookup_tag+0x34/0x54
 [<ffffffff810d99bb>] ? write_cache_pages+0x195/0x40c
 [<ffffffff811bde7a>] ? jbd2_journal_start+0x74/0x106
 [<ffffffff811bdebd>] ? jbd2_journal_start+0xb7/0x106
 [<ffffffff81197d6d>] ext4_da_writepages+0x33d/0x53a
 [<ffffffff810d9cb7>] do_writepages+0x3a/0x60
 [<ffffffff8113289c>] __writeback_single_inode+0x168/0x2a8
 [<ffffffff81132e0e>] generic_sync_sb_inodes+0x21a/0x361
 [<ffffffff811331cb>] writeback_inodes+0xb0/0x119
 [<ffffffff810d9ef0>] wb_kupdate+0xc0/0x14a
 [<ffffffff810daf57>] pdflush+0x163/0x25e
 [<ffffffff810d9e30>] ? wb_kupdate+0x0/0x14a
 [<ffffffff810dadf4>] ? pdflush+0x0/0x25e
 [<ffffffff81070171>] kthread+0x6d/0xae
 [<ffffffff810528e7>] ? schedule_tail+0x38/0xa3
 [<ffffffff8101310a>] child_rip+0xa/0x20
 [<ffffffff81070104>] ? kthread+0x0/0xae
 [<ffffffff81013100>] ? child_rip+0x0/0x20

Popularity on kerneloops is rising!

Just an update: I updated to Fedora 12 and the problem is still there. That's no news I guess, because the kerneloops is still very "popular".

Well, anyway: kernel-2.6.31.6-145.fc12.x86_68

------------[ cut here ]------------
WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a() (Tainted: P        W )
Hardware name: System Product Name
Modules linked in: fuse hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep nvidia(P) snd_seq snd_seq_device snd_pcm snd_timer snd soundcore amd64_edac_mod snd_page_alloc i2c_nforce2 hfcpci edac_core mISDN_core i2c_core serio_raw joydev k8temp ppdev parport_pc asus_atk0110 parport raid1 raid456 raid6_pq async_xor async_memcpy async_tx xor 8139cp pata_acpi 8139too ata_generic usb_storage mii forcedeth pata_amd sata_nv [last unloaded: scsi_wait_scan]
Pid: 1495, comm: updatedb Tainted: P        W  2.6.31.6-145.fc12.x86_64 #1
Call Trace:
 [<ffffffff810516f4>] warn_slowpath_common+0x84/0x9c
 [<ffffffff81051720>] warn_slowpath_null+0x14/0x16
 [<ffffffff8113e4c4>] dquot_claim_space+0xca/0x12a
 [<ffffffff8118d852>] ext4_mb_mark_diskspace_used+0x272/0x31a
 [<ffffffff81190522>] ext4_mb_new_blocks+0x1e4/0x3fe
 [<ffffffff8118710a>] ? ext4_ext_find_extent+0x53/0x279
 [<ffffffff81188dcb>] ext4_ext_get_blocks+0xb5c/0xcea
 [<ffffffff811e72df>] ? generic_make_request+0x24e/0x2ac
 [<ffffffff8101286e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff8141a8e0>] ? __down_write_nested+0x17/0xab
 [<ffffffff8141a998>] ? __down_read+0x17/0xaa
 [<ffffffff8116dc1e>] ext4_get_blocks+0x119/0x27b
 [<ffffffff8116de34>] mpage_da_map_blocks+0xb4/0x5da
 [<ffffffff810c9879>] ? pagevec_lookup_tag+0x25/0x2e
 [<ffffffff8116e86c>] ? __mpage_da_writepage+0x0/0x153
 [<ffffffff8116e619>] ext4_da_writepages+0x2bf/0x468
 [<ffffffff810c817c>] do_writepages+0x2d/0x3c
 [<ffffffff810c1ff8>] __filemap_fdatawrite_range+0x50/0x52
 [<ffffffff810c27b9>] filemap_flush+0x1c/0x1e
 [<ffffffff8116d19a>] ext4_alloc_da_blocks+0x30/0x32
 [<ffffffff811748db>] ext4_rename+0x608/0x624
 [<ffffffff8110617b>] vfs_rename+0x225/0x3c0
 [<ffffffff811bb417>] ? security_inode_permission+0x21/0x23
 [<ffffffff811075da>] sys_renameat+0x193/0x20c
 [<ffffffff81111a09>] ? mntput_no_expire+0x29/0xec
 [<ffffffff810fb331>] ? sys_fchmodat+0xb2/0xc5
 [<ffffffff811042e1>] ? path_put+0x22/0x27
 [<ffffffff81095e6c>] ? audit_syscall_entry+0x11e/0x14a
 [<ffffffff8110766e>] sys_rename+0x1b/0x1d
 [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
---[ end trace c9d7015b9c68d760 ]---

I'm also intrigued by the fact that this bug lives for so long. Perhaps it's no bug but a feature?

It's primarily a matter of time available from the ext4 development
community, plus the fact that very few of them run with quotas and/or
SELinux. 

The warning message is mostly harmless, but it's definitely a bug that we should fix.

Would you mind answering a few questions about your system configuration?

1) Can you reproduce it easily?  If so, what is the best reproduction
case?

2)  Do you have both user and group quotas enabled, or just user quotas?

3)  Do you have SELinux enabled?

Thanks!!

1) I initially had the problem on a Fedora 10->11 upgraded x86-64 system after converting ext3 to ext4 and enabling quota. Upgrading tot Fedora 12 did not solve the problem. Enabling or disabling SElinux has no effect, currently SElinux is permissive.
I then installed a fresh Fedora 12 KVM system, again x86_64. I created a custom file layout (/boot is ext3, / is ext4, apart from swap no other filesystems), but otherwise it's standard. SELinux is active (enforcing). After enabling quotas the reported problems showed up again.

2) Both user and group quotas are enabled

3) Yes and no. Two systems, enforcing or permissive makes no difference.

The warning message may be harmless, but it suggests there's at least something not working fine. To be more precise: are quota broken with ext4 or aren't they?

If quota are broken, people should stop using them on ext4, and they should be told.

If quota are OK, and ext4 is as well... then the message is harmless indeed, and should disappear. abrt is driving me (and itself) nuts with the huge amount of (harmless) messages that are processed.

Rolt, are you still encountering this problem with the 2.6.32 kernel on F12?

Thanks,
-Eric

Hm based on kerneloops.org, I suppose so.

Absolutely, this useless assertion still floods my syslog.

For what it's worth 2.6.34-rc1 has the following change:

commit 0a5a9c725512461d19397490f3adf29931dca1f2
Author: Jan Kara <jack>
Date:   Tue Feb 9 18:20:39 2010 +0100

    quota: Fix warning when a delayed write happens before quota is enabled
    
    If a delayed-allocation write happens before quota is enabled, the
    kernel spits out a warning:
    WARNING: at fs/quota/dquot.c:988 dquot_claim_space+0x77/0x112()
    
    because the fact that user has some delayed allocation is not recorded
    in quota structure.
    
    Make dquot_initialize() update amount of reserved space for user if it sees
    inode has some space reserved. Also make sure that reserved quota space does
    not go negative and we warn about the filesystem bug just once.
    
    Signed-off-by: Jan Kara <jack>

so for one, we only get one warning now ...

However, I wonder if there's a chance that fedora bootup is doing something to cause writes prior to quota enablement... or if we are getting out of sync in another way.

Actually this is the other piece needed, which handles writes prior to quotaon.

From: Dmitry Monakhov <dmonakhov>
Date: Tue, 9 Feb 2010 16:53:36 +0000 (+0100)
Subject: quota: manage reserved space when quota is not active [v2]
X-Git-Tag: v2.6.34-rc1~192^2~27

quota: manage reserved space when quota is not active [v2]

Since we implemented generic reserved space management interface,
then it is possible to account reserved space even when quota
is not active (similar to i_blocks/i_bytes).

Without this patch following testcase result in massive comlain from
WARN_ON in dquot_claim_space()

...

I'll do a little testing of this in the F12 kernel; it will be good to know if we actually are doing writes prior to quotaon or if there is some other accounting problem.

This may be informational, as it demonstrates the time the system is booted en the sh*tload of quota messages long after it's booted:

[root@home07 ~]# last | head
rolf     pts/1        :0.0             Tue Mar 30 23:32   still logged in   
rolf     pts/0        :0.0             Tue Mar 30 19:11   still logged in   
rolf     tty1         :0               Tue Mar 30 19:06   still logged in   
reboot   system boot  2.6.32.9-70.fc12 Tue Mar 30 19:04 - 23:35  (04:31)    
rolf     pts/1        :0.0             Tue Mar 30 08:22 - 08:22  (00:00)
   
[root@home07 ~]# grep dquot_claim_space /var/log/messages | tail -n 50
2010-03-30T23:31:49.372978+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:49.373078+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:49.384245+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:49.384597+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:49.384943+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:49.385052+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:54.384332+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:54.384454+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:54.384729+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:54.384829+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:59.394486+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:59.394614+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:59.394910+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:59.395012+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:32:29.428766+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:32:29.429044+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:32:29.429740+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:32:29.429863+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:32:59.429518+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:32:59.429636+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:32:59.429928+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:32:59.430029+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:33:29.485002+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:33:29.485515+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:33:29.487117+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:33:29.487345+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:33:59.495525+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:33:59.495643+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:33:59.495922+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:33:59.496024+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:34:29.511410+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:34:29.511912+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:34:29.512654+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:34:29.512869+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:34:59.511542+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:34:59.511659+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:34:59.511940+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:34:59.512042+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:35:29.544353+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:35:29.544472+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:35:29.544751+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:35:29.544853+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:35:59.580394+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:35:59.580560+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:35:59.580842+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:35:59.580944+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:36:29.641523+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:36:29.641641+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:36:29.641920+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:36:29.642022+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
[root@home07 ~]#

So, if there's a testable kernel, I think it's good if I give it a try.

I've got this reproducing just fine here, finally, so I'll poke at it a bit myself.  I'll let you know when there's something for you to test, ok?

Right now I have it on the stock f12 kernel; I first want to instrument it to see what the bad values are in this condition, then I'll likely test upstream to see if it's any different.

But what I'm seeing rules out "writes before quota was turned on" - this is clearly happening runtime, I think.

Thanks,
-Eric

Just for posterity, we're off by about this much:

inode 13866 reserved 0, claiming 4096
inode 13866 reserved 0, claiming 4096
inode 256521 reserved 0, claiming 4096
inode 256521 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 306162 reserved 0, claiming 4096
inode 306162 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 44925 reserved 0, claiming 4096
inode 330300 reserved 0, claiming 4096
inode 330300 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 101443 reserved 8192, claiming 12288
inode 101443 reserved 8192, claiming 12288
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 121139 reserved 8192, claiming 12288
inode 121139 reserved 8192, claiming 12288


So claiming one more block than reserved, and in some cases having reserved none.

I thought it could possibly be the selinux xattr block, but seems not - persists to some degree at least even w/o selinux enabled.

-Eric

I occasionally the warning messages mentioned in this bugzilla.

I don't know if it's related, but often when I call setquota(8) I also get these messages in syslog:


Mar 31 10:16:59 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 102818). There's a risk of filesystem corruption in case of system crash.
Mar 31 10:16:59 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 102818). There's a risk of filesystem corruption in case of system crash.

Perhaps this is related? I get these messages much more often than the other warnings here.

Norman, the spotted dirty metadata business probably needs to be its own bug ...

as far as the quota issue, 

http://marc.info/?l=linux-ext4&m=127004978200365&w=2

I proposed pushing 

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]

to -stable, they seem to fix things up on my box just fine.

Rolf, if you're able to compile your own kernels and want to test, go for it ...

One interesting tidbit is that quota complains that /etc/mtab was written before quota was turned on; I don't think there's any way around this! :)

-Eric

> Norman, the spotted dirty metadata business probably needs to be its own bug

OK, I've made bug 578674

I included the patches in 2.6.32.10-90.fc12.src.rpm and did a rebuilt. After installing the resulting kernel 2.6.32.10-90.fc12.x86_64 I did a reboot, and so far (5 minutes) no more disturbing messages. I'll check later again te see if all is still quiet.

Created attachment 403897 [details]
The spec for my modified 2.6.32.10-90.fc12.x86_64 kernel

This spec file includes the patches that may solve the dquot_claim_space messages, the patches in the spec are Patch20001 and Patch20002

Several hours later syslog is still quiet. And quota seem to work reliably.

So it looks like a fix!

Good deal, thanks.

After I pinged Jan, found out he'd already submitted the patches for -stable (just yesterday) :)

F12 just went to 32.11 so .12 might be a ways out; I'm putting the patches in cvs today.

Thanks,
-Eric

Committed to F12 CVS.

Sorry this one took so long.  :)

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.