From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF742C4332F for ; Fri, 25 Nov 2022 09:14:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63D8D6B0073; Fri, 25 Nov 2022 04:14:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5ECDF6B0074; Fri, 25 Nov 2022 04:14:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B3E96B0075; Fri, 25 Nov 2022 04:14:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 39C266B0073 for ; Fri, 25 Nov 2022 04:14:56 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 08459810EE for ; Fri, 25 Nov 2022 09:14:56 +0000 (UTC) X-FDA: 80171404992.18.63D5405 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf23.hostedemail.com (Postfix) with ESMTP id 4AABA140009 for ; Fri, 25 Nov 2022 09:14:55 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A872C21A9F; Fri, 25 Nov 2022 09:14:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669367693; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GGpt3ah8HnTK67kqx/nVgAelNcknoRSpTFcKqB3vIcc=; b=Jz1CMq+tDof0/AV6MyNJ5b3nvv29nKboiYJ5YuAe7NE+aoAMqYv0+dDePx/tVxKriEGg/2 grv54h1PS+EKPibaIaaYnCYtQ/IkkCqfw+56pkXrCXXlkvBo9azUrzAA6iRU1hgElGTasX FMOoQ0DAIkPVvn++oyIU/JozgiGfHk0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669367693; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GGpt3ah8HnTK67kqx/nVgAelNcknoRSpTFcKqB3vIcc=; b=LEWdEJF0KuyI9HKE1gjeQ96j9HUN1lOY4jT+V5iksglEtvrYyj/nfWI6lDuztmoOos/ZNv HzTrhZr7SOBKIwDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 963CA1361C; Fri, 25 Nov 2022 09:14:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fvSgJI2HgGNOQgAAMHmgww (envelope-from ); Fri, 25 Nov 2022 09:14:53 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 0B091A0714; Fri, 25 Nov 2022 10:14:53 +0100 (CET) Date: Fri, 25 Nov 2022 10:14:53 +0100 From: Jan Kara To: Lukas Czerner Cc: Jan Kara , Hugh Dickins , Jan Kara , Eric Sandeen , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH v2 2/3] shmem: implement user/group quota support for tmpfs Message-ID: <20221125091453.nm2lbxl743ggrqxq@quack3> References: <20221121142854.91109-1-lczerner@redhat.com> <20221121142854.91109-3-lczerner@redhat.com> <20221123163745.nnunvbl3s6th6kjx@quack3> <20221125085948.wbzzbimqeehcfqnh@fedora> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221125085948.wbzzbimqeehcfqnh@fedora> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669367695; a=rsa-sha256; cv=none; b=za0/Fu3QIiS2iJdFzBhZpG9kfcFpsmocIrnjD1OaYFzKf4tw+tDWuNoCpHHG6ixu44c4wB NIlnSeuFtrCRHYAon6h0ZpdaL8ePcTD7Hh8y4k5PBqeexiYTL/601xR7Pdr3PtTYa5x2Ut 0Gf2EjU4JXPxqrIQB3L4W3bdyvRVME8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Jz1CMq+t; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LEWdEJF0; spf=pass (imf23.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669367695; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GGpt3ah8HnTK67kqx/nVgAelNcknoRSpTFcKqB3vIcc=; b=IOnBVp3fqQMwhX3OWhqaqbpX38Wl6bkCiXrNkewtuy5UuOrDtzTQk9VP9Cvk6pTDf8CSxZ hWFC/AyHulNgcMFrvg/Du5k3wBCLpk9fagw7w8oeIfCzbHJ3wdXa+oNTZNNeuMGq0/75/7 UfhmDlLZhF/iLlFP4puIJNrNtlhIjmk= X-Stat-Signature: 73aw7gpwtck6ihkcfq7pk836ghs3jz8k X-Rspamd-Queue-Id: 4AABA140009 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Jz1CMq+t; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LEWdEJF0; spf=pass (imf23.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none X-Rspamd-Server: rspam10 X-HE-Tag: 1669367695-750876 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri 25-11-22 09:59:48, Lukas Czerner wrote: > On Wed, Nov 23, 2022 at 05:37:45PM +0100, Jan Kara wrote: > > On Mon 21-11-22 15:28:53, Lukas Czerner wrote: > > > Implement user and group quota support for tmpfs using system quota file > > > in vfsv0 quota format. Because everything in tmpfs is temporary and as a > > > result is lost on umount, the quota files are initialized on every > > > mount. This also goes for quota limits, that needs to be set up after > > > every mount. > > > > > > The quota support in tmpfs is well separated from the rest of the > > > filesystem and is only enabled using mount option -o quota (and > > > usrquota and grpquota for compatibility reasons). Only quota accounting > > > is enabled this way, enforcement needs to be enable by regular quota > > > tools (using Q_QUOTAON ioctl). > > > > > > Signed-off-by: Lukas Czerner > > > > ... > > > > > diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst > > > index 0408c245785e..9c4f228ef4f3 100644 > > > --- a/Documentation/filesystems/tmpfs.rst > > > +++ b/Documentation/filesystems/tmpfs.rst > > > @@ -86,6 +86,18 @@ use up all the memory on the machine; but enhances the scalability of > > > that instance in a system with many CPUs making intensive use of it. > > > > > > > > > +tmpfs also supports quota with the following mount options > > > + > > > +======== ============================================================= > > > +quota Quota accounting is enabled on the mount. Tmpfs is using > > > + hidden system quota files that are initialized on mount. > > > + Quota limits can quota enforcement can be enabled using > > ^^^ and? > > > > > + standard quota tools. > > > +usrquota Same as quota option. Exists for compatibility reasons. > > > +grpquota Same as quota option. Exists for compatibility reasons. > > > > As we discussed with V1, I'd prefer if user & group quotas could be enabled > > / disabled independently. Mostly to not differ from other filesystems > > unnecessarily. > > Ok, but other file systems (at least xfs and ext) differs. Mounting ext4 > file system with quota feature with default quota option settings will > always enable accounting for both user and group. Mount options quota, > usrquota and grpquota enables enforcement; selectively with the last > two. > > On xfs with no mount options quota is disabled. With quota, usrquota and > grpquota enforcement is enabled, again selectively with the last two. > > And yes, with this implementation tmpfs is again different. The idea was > to allow enabling accounting and enforcement (with default limits) > selectively. > > So how would you like the tmpfs to do it? I think having accounting only > can be useful and I'd like to keep it. Maybe adding qnoenforce, > uqnoenforce and qgnoenforce mount options, but that seems cumbersome to > me and enabling accounting by default seems a bit much. What do you think? So I wanted things to be as similar to other filesystems as possible. So quota, usrquota, grpquota would enable quota accounting & enforcement (the last two selectively). If we want the possibility to enable accounting without enforcement that can be done by some special mount options (and possibly we can add them when there's user demand). Also note that there's always the possibility to disable quota enforcement using quota tools when needed. But IMHO 99% of users will want accounting & enforcement and thus that should be the default like with other filesystems. Honza -- Jan Kara SUSE Labs, CR