From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: quota tests Date: Tue, 6 Sep 2011 11:15:05 -0400 Message-ID: <20110906151505.GA7213@infradead.org> References: <20110906122116.GA31290@infradead.org> <20110906144334.GE23747@quack.suse.cz> <20110906145008.GA17593@infradead.org> <20110906151236.GG23747@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:59296 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754766Ab1IFPPH (ORCPT ); Tue, 6 Sep 2011 11:15:07 -0400 Content-Disposition: inline In-Reply-To: <20110906151236.GG23747@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Sep 06, 2011 at 05:12:36PM +0200, Jan Kara wrote: > To verify reclaim behavior for VFS quotas, we could pull quota structures > in memory using GETQUOTA and then apply memory pressure to have them > reclaimed. If we also want to combine this with updates to those structures > because of allocations it gets more complicated. We'd have to do IO for > several different users in sequence under memory pressure so that all > inodes of one user get pushed out of memory and quota structure is thus > freed for reclaim as well. > > As for racing lookups / other quota operations - these are not that > much interesting for VFS quotas because > a) once quota structure is created, it's position on disk is fixed > b) any operation on quota file that does more than update accounting > information in a structure is protected by per quota-file mutex. > c) in memory operations with quota structures are protected by one global > spinlock It's fairly similar for XFS - but we still have code to e.g. retry the lookup after we did a memory allocation in both quota implementation. I just change the way the one in XFS worked, so I'm looking for a way to actually test that path.