[Top] [All Lists]

Re: OOM on quotacheck (again?)

Subject: Re: OOM on quotacheck (again?)
From: Volker <mail@xxxxxxxxxx>
Date: Thu, 20 Sep 2012 11:32:17 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20120919205924.GC31501@dastard>
References: <5059D2B4.8010300@xxxxxxxxxx> <20120919205924.GC31501@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

> 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 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 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

<Prev in Thread] Current Thread [Next in Thread>