I remember that there used to be a problem with disk quotas on Ext3 and Raid5 on the 2.4.x kernel series. I am running 2.4.14 with Ext3 and Raid5 and am having problems with quotas and am wondering if I have something misconfigured or if this combination doesn't work yet. -- Daniel R. Bidwell | bidwell@andrews.edu Andrews University Information Technology Services If two always agree, one of them is unnecessary "Friends don't let friends do DOS" "In theory, theory and practice are the same. In practice, however, they are not." No tema al pinguino.
Daniel Bidwell wrote:> > I remember that there used to be a problem with disk quotas on Ext3 and > Raid5 on the 2.4.x kernel series. I am running 2.4.14 with Ext3 and > Raid5 and am having problems with quotas and am wondering if I have > something misconfigured or if this combination doesn't work yet.Quotas are hard to get running for some reason. The tools are a bit fiddly. Alan's kernel has the new quota format. Linus' kernel has the old format, but somebody has recently made large changes to the code in Linus' tree. But it still uses the old format quota files. There are no known problem with ext3 and quotas in -ac kernels. In linus kernels, ext3 used to be able to cause deadlocks (tasks stuck in D state) under heavy load with quotas. I _think_ the recent quota changes in Linus' tree have fixed this, but I need to test/check some more. If you're seeing something other than processes stuck in D state then it's probably some generic setup problem. Try getting quotas working while mounting the filesystem as ext2 to eliminate the ext3 possibility. -
The following error occurs on a test machine with 2.4.14 and
ext3-2.4-0.9.15-2414 patch. The filesystem is on a Western Digital IDE
drive. It occurs fairly quickly with a 2 process workload.
EXT3 FS 2.4-0.9.15, 06 Nov 2001 on ide1(22,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Assertion failure in journal_bmap() at journal.c:636: "ret != 0"
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0163b29>] Not tainted
EFLAGS: 00010282
eax: 00000044 ebx: 00000000 ecx: 00000000 edx: 0000002f
esi: c9253ec4 edi: c9253ec8 ebp: cb765d40 esp: c9253e48
ds: 0018 es: 0018 ss: 0018
Process kjournald (pid: 4290, stackpage=c9253000)
Stack: c0291300 c02913c7 c02912d1 0000027c c02913be cff41c00 c0163ae3
cff41c00
00000266 cff41c00 c0163b43 cff41c00 ca02abe0 c01612d5 cff41c00
cff41c00
cff41c50 cff41a00 00000000 00000000 00006219 c9253ec8 c9252000
cff41c94
Call Trace: [<c0163ae3>] [<c0163b43>] [<c01612d5>]
[<c0163610>] [<c01634c0>]
[<c01055db>]
Code: 0f 0b 83 c4 14 eb 02 89 d3 89 d8 5b c3 89 f6 53 8b 5c 24 08
Anyone have any ideas?
-RW