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 X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5055C282C0 for ; Wed, 23 Jan 2019 09:43:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA53C20861 for ; Wed, 23 Jan 2019 09:43:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727202AbfAWJnK (ORCPT ); Wed, 23 Jan 2019 04:43:10 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:50953 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726359AbfAWJnJ (ORCPT ); Wed, 23 Jan 2019 04:43:09 -0500 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gmF3r-00018i-Mr; Wed, 23 Jan 2019 10:43:07 +0100 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gmF3p-0000nX-TB; Wed, 23 Jan 2019 10:43:05 +0100 Date: Wed, 23 Jan 2019 10:43:05 +0100 From: Sascha Hauer To: Richard Weinberger Cc: Jan Kara , Christoph Hellwig , linux-fsdevel , Dongsheng Yang , Richard Weinberger , linux-mtd@lists.infradead.org, kernel@pengutronix.de Subject: Re: UBIFS quota support Message-ID: <20190123094305.7owpfwzgtzz2snat@pengutronix.de> References: <20190110114448.vcx6w76ibmxwvlh3@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 10:16:59 up 1 day, 20:30, 57 users, load average: 0.27, 0.23, 0.20 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-fsdevel@vger.kernel.org Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Jan 23, 2019 at 12:07:12AM +0100, Richard Weinberger wrote: > On Thu, Jan 10, 2019 at 12:45 PM Sascha Hauer wrote: > > > > Hi all, > > > > I'm currently working on resurrecting the UBIFS quota patches posted back in > > 2015 by Dongsheng Yang, last posted here: > > > > http://lists.infradead.org/pipermail/linux-mtd/2015-September/061812.html > > > > First of all I think work stopped there, there is no newer UBIFS quota > > support I am missing, right? > > > > One problem with this series was that the quotactl systemcall expects a > > path to a block device. UBIFS doesn't work on a block device but on a > > character device instead. > > The solution in this series was to pass the path to the cdev in > > quotactl. A struct cdev * member was added to struct super_block which > > was used to identify the superblock for a given cdev. This approach was > > rejected by Christoph ("I don't think the cdev has any business in core > > VFS code."). Apart from that UBIFS can not only be mounted with a path > > to the character device (mount -t ubifs /dev/ubix_y /mnt) but also in > > the form ubix:volname (mount -t ubifs ubix:volname /mnt) in which case > > userspace doesn't have any valid path it could pass in quotactl. > > > > An idea out of this would be to allow to pass the mountpoint instead of > > the path to the block device in quotactl which would work with nfs or > > even tmpfs aswell. Would that be acceptable? Any other ideas? > > *kind ping* > > Jan, another thing Sascha and I are not sure about, what are the consistency > constraints of the quota file? > If I read the code correctly, quota just writes to the quota file and > assumes that > the file system makes sure about consistency. Either by fsckfixing the quota > file or having a data journal for the quota file. > In case of UBIFS where we have a data journal this should be doable. > Is it okay when the quota file has S_SYNC set? S_SYNC won't help us. We need to make sure that a change of an inode and the corresponding update to the quota file is done atomically. Otherwise it may happen that we only change the size of an inode, but miss the corresponding quota updates, or depending on the implementation, maybe the other way round. ext4 does this with transactions. As an example with ext4_setattr(): ext4_setattr() -> handle = ext4_journal_start(inode, EXT4_HT_QUOTA, ...) -> dquot_transfer(inode, attr); -> After going through the quota code with several calls back into ext4 ends up in ext4_quota_write() which updates the quota file -> change inode -> ext4_mark_inode_dirty(handle, inode) -> ext4_journal_stop(handle); Everything between ext4_journal_start() and ext4_journal_stop() is either done or not. The analogy in UBIFS is the grouped nodes, but these are not very well suited to be initialized in one function and arbitrarily extended somewhere further down the call stack. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | 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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7B9CC282C0 for ; Wed, 23 Jan 2019 09:43:20 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A5F4620861 for ; Wed, 23 Jan 2019 09:43:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Pr6IMDj2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5F4620861 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HgJMMkWJZmTwaTmjqIRZVn+hWaEtxlyy9yzMIwmuDgY=; b=Pr6IMDj2aHV9fp TqFko9EbhkcNG5xhwmKgsl2MiaMUbX0Vb192bwtazLIydCcp5bL1np9+2VgzgFKrqIjJpQ84vEVrn Hs6OtIzrUxFgcfyd84I5jQYdobeWz2Xpfb+aJs3BsYiWi2GeLihS+Nlkvw0SPMjZDe8fgT79xoiwT V4QFaWKhSi9J1vsx/bqCqSk1NaqlaM3B4IsUbSeUkC+9pSKq9ra1KROXG5+GVZhuDXdwkY4nHPcxZ G0+3kJ4RWBZfYOroLcYdyA2PXADPccPnwY1wjCBCbQuo3mnrQ43f4xo5G4ZVADpGQGwQgedGMC8zN nHyG4VpzKv/O/gdxWepg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gmF42-00069F-JH; Wed, 23 Jan 2019 09:43:18 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gmF3z-00068v-Iu for linux-mtd@lists.infradead.org; Wed, 23 Jan 2019 09:43:17 +0000 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gmF3r-00018i-Mr; Wed, 23 Jan 2019 10:43:07 +0100 Received: from sha by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gmF3p-0000nX-TB; Wed, 23 Jan 2019 10:43:05 +0100 Date: Wed, 23 Jan 2019 10:43:05 +0100 From: Sascha Hauer To: Richard Weinberger Subject: Re: UBIFS quota support Message-ID: <20190123094305.7owpfwzgtzz2snat@pengutronix.de> References: <20190110114448.vcx6w76ibmxwvlh3@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 10:16:59 up 1 day, 20:30, 57 users, load average: 0.27, 0.23, 0.20 User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mtd@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190123_014315_780542_9D6F328C X-CRM114-Status: GOOD ( 25.79 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dongsheng Yang , Jan Kara , Richard Weinberger , Christoph Hellwig , linux-mtd@lists.infradead.org, kernel@pengutronix.de, linux-fsdevel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Jan 23, 2019 at 12:07:12AM +0100, Richard Weinberger wrote: > On Thu, Jan 10, 2019 at 12:45 PM Sascha Hauer wrote: > > > > Hi all, > > > > I'm currently working on resurrecting the UBIFS quota patches posted back in > > 2015 by Dongsheng Yang, last posted here: > > > > http://lists.infradead.org/pipermail/linux-mtd/2015-September/061812.html > > > > First of all I think work stopped there, there is no newer UBIFS quota > > support I am missing, right? > > > > One problem with this series was that the quotactl systemcall expects a > > path to a block device. UBIFS doesn't work on a block device but on a > > character device instead. > > The solution in this series was to pass the path to the cdev in > > quotactl. A struct cdev * member was added to struct super_block which > > was used to identify the superblock for a given cdev. This approach was > > rejected by Christoph ("I don't think the cdev has any business in core > > VFS code."). Apart from that UBIFS can not only be mounted with a path > > to the character device (mount -t ubifs /dev/ubix_y /mnt) but also in > > the form ubix:volname (mount -t ubifs ubix:volname /mnt) in which case > > userspace doesn't have any valid path it could pass in quotactl. > > > > An idea out of this would be to allow to pass the mountpoint instead of > > the path to the block device in quotactl which would work with nfs or > > even tmpfs aswell. Would that be acceptable? Any other ideas? > > *kind ping* > > Jan, another thing Sascha and I are not sure about, what are the consistency > constraints of the quota file? > If I read the code correctly, quota just writes to the quota file and > assumes that > the file system makes sure about consistency. Either by fsckfixing the quota > file or having a data journal for the quota file. > In case of UBIFS where we have a data journal this should be doable. > Is it okay when the quota file has S_SYNC set? S_SYNC won't help us. We need to make sure that a change of an inode and the corresponding update to the quota file is done atomically. Otherwise it may happen that we only change the size of an inode, but miss the corresponding quota updates, or depending on the implementation, maybe the other way round. ext4 does this with transactions. As an example with ext4_setattr(): ext4_setattr() -> handle = ext4_journal_start(inode, EXT4_HT_QUOTA, ...) -> dquot_transfer(inode, attr); -> After going through the quota code with several calls back into ext4 ends up in ext4_quota_write() which updates the quota file -> change inode -> ext4_mark_inode_dirty(handle, inode) -> ext4_journal_stop(handle); Everything between ext4_journal_start() and ext4_journal_stop() is either done or not. The analogy in UBIFS is the grouped nodes, but these are not very well suited to be initialized in one function and arbitrarily extended somewhere further down the call stack. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/