> Which implies you are running a 32 bit kernel even on 64 bit CPUs
> (e.g. R710).
My mistake. That is not yet the case, but the plan for the future.
Thanks for pointing that out.
> No surprise if you are running an i686 kernel (32 bit). You've got
> way more inodes than can fit in the kernel memory segment.
Could you slightly elaborate on that or give me a link or two which
explain the matter?
If a 32bit kernel is not supposed to work because of the number of
inodes, why does the 18.104.22.168-kernel work flawlessy on quota-checks on
the same filesystem a 3.6.0-rc5 32bit (which is supposed to work) fails on?
Doesn't that imply, that the fix submitted for 22.214.171.124 fixed a problem
which was "reinvented" by the later patch, which is now being worked
around by using a 64bit kernel for more memory?
> Running on a x86-64 kernel will make the vmalloc problem go away.
> There's very little we can do about the limited vmalloc address
> space on i686 kernels. As it is, the known recent regression in this
> bcf62ab xfs: Fix overallocation in xfs_buf_allocate_memory()
> $ git describe --contains bcf62ab
> was fixed in 3.6-rc1,
Confirmed. The current 3.6.0-rc5 in 64bit works doing the quota-check.
I'll do some more testing with xfs_fsr etc. and report back.