From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sandeen.net ([63.231.237.45]:37289 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754537AbcAORbC (ORCPT ); Fri, 15 Jan 2016 12:31:02 -0500 Subject: Re: [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2 To: Jan Kara References: <568FEA2C.6080708@redhat.com> <20160109072600.GA21636@infradead.org> <20160111132617.GD6262@quack.suse.cz> <5693D33A.5090307@sandeen.net> <20160111162807.GK6262@quack.suse.cz> <5696D27A.9070700@sandeen.net> <20160115093507.GA15950@quack.suse.cz> Cc: Christoph Hellwig , fsdevel , Eric Sandeen , xfs@oss.sgi.com From: Eric Sandeen Message-ID: <56992CD4.6030408@sandeen.net> Date: Fri, 15 Jan 2016 11:31:00 -0600 MIME-Version: 1.0 In-Reply-To: <20160115093507.GA15950@quack.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Jan - On 1/15/16 3:35 AM, Jan Kara wrote: > On Wed 13-01-16 16:40:58, Eric Sandeen wrote: >> On 1/11/16 10:28 AM, Jan Kara wrote: ... >>> Actually, what I want from you is just an interface which is usable for VFS >>> quotas as well since I'd like to avoid adding GETQUOTA2 quotactl shortly >>> after XGETQUOTA2 :). >> >> Actually, that's exactly what I thought would *need* to happen ... we already >> have this weird 15-year-old split-brain quota interface, so if xfs and ext4 >> both need the same functionality, then we'd probably add both GETQUOTA2 and >> XGETQUOTA2. If we were doing this all from scratch, sure, but adding a new >> handles-both-quota-types interface when every other operation is already split >> between the two almost seems to make matters worse. > > Well, currently GETQUOTA and XGETQUOTA (and all the other quotactls) are > actually translated so they work regardless of the underlying filesystem. > So the only difference between XFS and VFS quotactls is in the formatting > of input/output structures. So from kernel POV it seems somewhat pointless > to add two calls doing the same thing and differing just in the formatting > of output - especially when we want the call to be extensible. > > I agree that having a unified call means having a new structure for passing > dquot info between kernel and userspace. So just for adding that one small > feature you want it seems like an overkill. But when thinking about new > extensible getquota quotactl it IMHO makes sense to unify the VFS/XFS split > brain. Thoughts? My first lazy/hacky thought is "how terrible would it be to overload the quotactl syscall return value with quota ID for Q_GETQUOTA2 calls?" For a purpose-built interface of "find the next ID" that wouldn't require any structure or interface changes... We could name it Q_GETNEXTQUOTA / Q_XGETNEXTQUOTA to make it explicit about the purpose, and document that return behavior. Done & done. ;) A new grand unified extensible quota call sounds like a great idea, I just hate to gate this work on designing a brand-new interface. -Eric