Hi, > 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 2.6.39.4-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 2.6.39.4 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 > space: > > bcf62ab xfs: Fix overallocation in xfs_buf_allocate_memory() > > $ git describe --contains bcf62ab > v3.6-rc1~42^2~35 > > 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. best regards volker _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
