Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3318363imm; Fri, 25 May 2018 03:44:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqFaYTfoLtpJ3Kjd60QIK8Br91zlp1Iky5I75gjS0ElpoUxrCBWXdIckr+U6AN0XnDvWdVX X-Received: by 2002:a17:902:1347:: with SMTP id r7-v6mr2044879ple.62.1527245069259; Fri, 25 May 2018 03:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527245069; cv=none; d=google.com; s=arc-20160816; b=e8U0YAE2t0qAfoQOZC8fVGZ26EQFECWKR26ZHYce1irGrrcShJGGgsPeCZaO8Nrb4+ VpcDhWU4/9gsEs9q+b5cABUZLftOPdZJ1H3p4OhDKf7+4R9oJk5cpz0OaCwVJeX0RlgV a6A3uV9vw7KZ7tyA/PauscVAT3/8R/TtQvMwf4HRUpgqIt1b2Z7M4LXas4YRYm+BBEYb BxgVgeP4cjIPqcVLNa+ztuJXnrouIHst6VlvR16dylJdNqhEghcMZQ17k9eKUEOz1ZRU G9tFnjNRES1xDRbpSm3VR+Ky/wuAsBEyi6jLVBJE1BB1xvd9IuqsdFwWXc3gN6ZvKNt+ NgNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:references:in-reply-to:cc :to:subject:from:arc-authentication-results; bh=ODHKNoccOrWpMujVFL9hV6/LCNjr2By/2p2xbniVL5I=; b=TZXdFTe9MheNWaRMplDbcSB82K8FZOjjBdHFTkpBXvSxtMkv17IFaBIT4tq2N6PhiS h6T5Rdwkrecf1V8T4dBuMWfMGPVMF6YDUE7zNPNycg1R6gpwGgLY1HgRbgTSOHT8l5qA M6E/PrcMQRehza//k58XL8kxZGTRcuPxphDeFentxbmz96xb6g1D52lbh010gHL9V1OH RhA5sLSxkBb+aXtIhyr7bZarcdxrvS1Hq7s5UidJ5Y9I1zlQPnPgaNj+U3FY3GlT9k0A Ux8f5BrOkgXht4wrAvbCdnzuVGvkN/k1AuxBJm50CiU7lwkuY0hG3XBgwigEzKVIPvFv ZEBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1-v6si18825052pge.248.2018.05.25.03.44.13; Fri, 25 May 2018 03:44:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966081AbeEYKmN (ORCPT + 99 others); Fri, 25 May 2018 06:42:13 -0400 Received: from mail05-md.ns.itscom.net ([175.177.155.115]:60656 "EHLO mail05-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965731AbeEYKmM (ORCPT ); Fri, 25 May 2018 06:42:12 -0400 Received: from scan27-mds.s.noc.itscom.net (scan27-md.ns.itscom.net [175.177.155.81]) by mail05-md-outgoing.ns.itscom.net (Postfix) with ESMTP id A5D9C658515; Fri, 25 May 2018 19:42:10 +0900 (JST) Received: from unknown (HELO mail01-md-outgoing.ns.itscom.net) ([175.177.155.111]) by scan27-mds.s.noc.itscom.net with ESMTP; 25 May 2018 19:42:11 +0900 Received: from jromail.nowhere (h116-0-242-084.catv02.itscom.jp [116.0.242.84]) by mail01-md-outgoing.ns.itscom.net (Postfix) with ESMTP; Fri, 25 May 2018 19:42:10 +0900 (JST) Received: from jro by jrobl id 1fMAAk-0001TT-Bb ; Fri, 25 May 2018 19:42:10 +0900 From: "J. R. Okajima" Subject: Re: Why is the length of max mount option a page size?? To: Jungsub Shin Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20180521173959.GA12779@supsup-VirtualBox> References: <20180521173959.GA12779@supsup-VirtualBox> Date: Fri, 25 May 2018 19:42:10 +0900 Message-ID: <5670.1527244930@jrobl> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jungsub Shin: > I know that almost mount option short and page size is enough to > contain almost mount options. but because of options for > unionfs(overlay, aufs), lenght of mount option could be exceed it > and cut. > > I suffer this problem with aufs. aufs's branch option is cut and > fail to aufs mount. I know that aufs is not offical fs in linux, For aufs, it should not happen because of the module parameter 'brs.' (from the aufs manual) ---------------------------------------------------------------------- .SH Module Parameters .TP .B brs=1 | 0 Specifies to use the branch path data file under sysfs or not. If the number of your branches is large or their path is long and you meet the limitation of mount(8) ro /etc/mtab, you need to enable CONFIG_SYSFS and set aufs module parameter brs=1. When this parameter is set as 1, aufs does not show `br:' (or dirs=) mount option through /proc/mounts (and /etc/mtab). So you can keep yourself from the page limitation of mount(8) or /etc/mtab. Aufs shows branch paths through /fs/aufs/si_XXX/brNNN. Actually the file under sysfs has also a size limitation, but I don't think it is harmful. There is one more side effect in setting 1 to this parameter. If you rename your branch, the branch path written in /etc/mtab will be obsoleted and the future remount will meet some error due to the unmatched parameters (Remember that mount(8) may take the options from /etc/mtab and pass them to the systemcall). If you set 1, /etc/mtab will not hold the branch path and you will not meet such trouble. On the other hand, the entries for the branch path under sysfs are generated dynamically. So it must not be obsoleted. But I don't think users want to rename branches so often. If CONFIG_SYSFS is disable, this parameter is always set to 0. ---------------------------------------------------------------------- If you post the details of your environment to aufs-users ML, then I may be able to describe more. J. R. Okajima