Received: by 10.223.185.116 with SMTP id b49csp4177888wrg; Tue, 6 Mar 2018 11:05:15 -0800 (PST) X-Google-Smtp-Source: AG47ELvfoBstu32+gaLtQoDDorpverTPmD8NppOV1pZ4VsKaEg/HuYopzUNIOLAVob5p8JE7cN1h X-Received: by 10.99.166.10 with SMTP id t10mr15872925pge.198.1520363115265; Tue, 06 Mar 2018 11:05:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520363115; cv=none; d=google.com; s=arc-20160816; b=yOcftZOlFwYS55bply/y1QTf+q1AuY1qmJqJ1QRUmHUHMYuLD6Ag1AJrHLoJdCndfE H5muffQv1fzUIuc0s/w9S1RmR/4QG35yy6KXjCtgLCLpvUGUNyNsMpNlA9kCq0QdAuy5 4yjRlhwYQFp+JWgpQ1ApGTvnLqRf+MTm2t6wd/qQWzKIj+aZaKD0NaXYCYXJwHdQAAYe cTJmnsbU9aL11kzrtA9m6kQx9ON4FaiwgfhkxObdtrrfAKeCecxQGRW3/IDdTEoA3mPA 4LBof2xkzkbiU9VWO6f9g6ZZX8mju9KEjheOSrw8+0TCkUWP2FLDf578bdWhf1TJ1pob o1rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:from:user-agent:content-disposition :mime-version:message-id:subject:cc:to:date :arc-authentication-results; bh=CtCoZESky1VCxCQPQP2L5Ow8dR+RG+/ichVVqJBIx/s=; b=Pu9Y8MY9DqBKV0Rhlb+IBJlFSSxtchAiR0UktnUO4QuVbrAefpD6OlCIXFvVO2zJvo 6zZ4ESV0OYDNxs4JjtzFQQRxVgpJWAqkxSRjLGpOHFNLwllH6tB4vs6bb73MqdCBcqqB w3d5Sm0vU47zmM84HLRb7FUL60YkLw45gc5eaCpYbyqCHO3pfVTr9/dBiCFa1hY+NvbT uyEFxvSuiOMtg/sR8JSoAzXPKpsloP7PTdzHDz//aBzPI9dPoX9bpT5+tyXC7UBwGMt2 oDE8UPzcjKCOjPDPOj4a/cPQtC+ayCdyzEi8tK34gylRNFrWq24QMfkL+PukIz9z/0dk zkqQ== 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=NONE dis=NONE) header.from=csclub.uwaterloo.ca Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c200si12345498pfb.373.2018.03.06.11.04.59; Tue, 06 Mar 2018 11:05:15 -0800 (PST) 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=NONE dis=NONE) header.from=csclub.uwaterloo.ca Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932906AbeCFTDS (ORCPT + 99 others); Tue, 6 Mar 2018 14:03:18 -0500 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:35047 "EHLO caffeine.csclub.uwaterloo.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753466AbeCFTDR (ORCPT ); Tue, 6 Mar 2018 14:03:17 -0500 Received: by caffeine.csclub.uwaterloo.ca (Postfix, from userid 20367) id CB37DC15A1; Tue, 6 Mar 2018 14:03:15 -0500 (EST) Date: Tue, 6 Mar 2018 14:03:15 -0500 To: Theodore Ts'o Cc: Andreas Dilger , Len Sorensen , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: ext4 ignoring rootfs default mount options Message-ID: <20180306190315.puocf5bu3bfz6yct@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org While switching a system from using ext3 to ext4 (It's about time) I discovered that setting default options for the filesystem using tune2fs -o doesn't work for the root filesystem when mounted by the kernel itself. Filesystems mounted from userspace with the mount command use the options set just fine. The extended option set with tune2fs -E mount_opts= works fine however. I am sure those using an initrd works fine (and hence why almost noone would ever see this bug) since that uses the mount command from userspace to mount the rootfs. Specifically we did: tune2fs -o nodelalloc /dev/sda1 at boot we got: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) Instead using: tune2fs -E mount_opts=nodelalloc /dev/sda1 at boot we got: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: nodelalloc; (null) which seems better. For filesystems mounted from userspace with the mount command, either method works however. The first option however is what the comment in fs/ext4/super.c suggests to use. Of course I also got the messages: EXT4-fs (sda1): Mount option "nodelalloc" incompatible with ext3 EXT4-fs (sda1): failed to parse options in superblock: nodelalloc EXT4-fs (sda1): couldn't mount as ext3 due to feature incompatibilities Those of course all ought to not be there. If it is ext4, I don't really care if ext3 doesn't understand the options, it works fine with ext4. I should not have to explicitly specify that it is ext4 just to avoid those. It is not an ext3 filesystem. And of course the last annoying thing I noticed is that /proc/mounts doesn't actually tell you that nodelalloc is active when it is set from the default mount options rather than from the mount command line (or fstab). Lots of other non default options are explicitly handled, but not delalloc. The only place you see it, is in the dmesg line telling you what options the filesystem was mounted with. -- Len Sorensen