Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp731286pxt; Thu, 12 Aug 2021 08:23:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiKLBaMIgSf6tw/s8d4IwGXvglqHPpSpyhjZYcaKCwh4MHo2+Q3fXcvKbwkm/KA+Z2JU7j X-Received: by 2002:a17:907:2ce7:: with SMTP id hz7mr4176174ejc.35.1628781806316; Thu, 12 Aug 2021 08:23:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628781806; cv=none; d=google.com; s=arc-20160816; b=PkdJxr82YyYazyGqMrk7VhWX3dxmaeqqb4jwdPMIL7NqfEn+MATOytOWOPUt8tPTK3 Cfv01eZSckZ/d+XqV3mvlBz2GrnsGGJKTapvITojJnNoqDs/doRa/53+sBZtuwRr6P6z yDOGLwFMNIDS00bTGRz3sUoJV6iYKbKj8O5ov3agY2Ywn+4wiiNNr6yVZj8z0WwHXiF3 kCPYOd1KaBXTNC1ZdT2nVN7YSelreR9q2DODa1Msy8TI6PuLy+GH6wzqA5E494GuBwrX IenBYd9+hNRJHDQ1zMUea40Uqddyowcu4LpPRAmsOzsz5XQxSROH3sD6ticSFg0+QPWs 8l2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FvV/dBMtVyC9v9P5i3IZDR5L2tEmJA0ond6gxrR1ZzA=; b=dzMKCFgDG6MfbpNhWhQCC+7zEoeEhfEj/3AqZ5SXyQjqgzdIOEtSYjHmVJEcnhOvAN yN2c9toRN0rrWUA1K1n1BiKfZbXxmC+cziE4XTb9e3p4Z9XOuzXDSjInyOWV6IXK2Tp9 N8Zf3jAmmgshW8zZ5ibjB6JEf51lbPZAAJ4xpo1vwhpS4ulHIwrrZQ+VnIMgGizziM2i HfSyjKs3Fu9FEfNY6VTwtdTDSfveJ+lGlnJ0SYGipwjFcb5oFN3mcu8tmBEDzCBzMmsf WnMiAxXTKhtTkh7Uub2o70O8WJA7nzmueFqlKaAmS9+PZUV2o0ZmZlLijvOw0OLImy5m JAJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mT6KYmi9; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nd38si2716645ejc.558.2021.08.12.08.23.01; Thu, 12 Aug 2021 08:23:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mT6KYmi9; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238304AbhHLPF7 (ORCPT + 99 others); Thu, 12 Aug 2021 11:05:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:35320 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234850AbhHLPF6 (ORCPT ); Thu, 12 Aug 2021 11:05:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CCCBF6103A; Thu, 12 Aug 2021 15:05:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628780732; bh=xB0xau6mobE/BCCOoCDk4Aa0L9ouSA0Uui8dc7NhZCw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mT6KYmi9kWpByxh0dtNYmJMAb0kdISnL3Cu9mHlbS9m6Aij3KplxUh6/zp/uq/1xs tdUo5OIhAEZqKwwYmuuUTokTfmw1dx5iTckGo1YChJg44fukm3tuHqtvrpYPTLKE+j ACzi4vg0USw6db3DjNDdpHcmnbEaeOx1CJab3g7TfWzKhxpLovM4RWoznwt3UJLihz h1mw5+MLboILfz06Vg1x7970xG/rsRjbr+oJYDNI/IALpr/jhs8OyGWK9tr30yNj1h 52FGg1NSafyApYHwxrjL6zJELVGbue7v81a35BZY1sGhrP5UJN3oLwmVTT/GY10fB3 OtSQ2siUaMxgA== Date: Thu, 12 Aug 2021 08:05:32 -0700 From: "Darrick J. Wong" To: Theodore Ts'o Cc: linux-ext4 Subject: Re: [PATCH] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs Message-ID: <20210812150532.GD3601392@magnolia> References: <20210811233253.GC3601392@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Aug 11, 2021 at 09:25:18PM -0400, Theodore Ts'o wrote: > On Wed, Aug 11, 2021 at 04:32:53PM -0700, Darrick J. Wong wrote: > > +/* > > + * Returns true if the user is forcing an old format (e.g. ext2, ext3). > > + * > > + * If there is no fs_types list, the user invoked us with no explicit type and > > + * gets the default (ext4) format. If we find the latest format (ext4) in the > > + * type list, some combination of program name and -T argument put us in ext4 > > + * mode. Anything else (ext2, ext3, hurd) and we return false. > > + */ > > So that's not actually quite right. Even if the user has no explicit > type, mke2fs will assign a default type --- and it's not necessarily > ext4. You can see what the contents of the fs_types list using the -v > option: Ok, fair, I'll fix the message. "If the user invoked us with no explicit type, mke2fs adds some variant of ext* to the type list by default." > % /bin/rm /tmp/foo.img ; mke2fs -vq /tmp/foo.img 8m > fs_types for mke2fs.conf resolution: 'ext2', 'small' > % /bin/rm /tmp/foo.img ; mke2fs -vq -T news /tmp/foo.img 8m > fs_types for mke2fs.conf resolution: 'ext2', 'news' > % /bin/rm /tmp/foo.img ; mkfs.ext4 -vq /tmp/foo.img 8m > fs_types for mke2fs.conf resolution: 'ext4', 'small' > % /bin/rm /tmp/foo.img ; mkfs.ext4 -T huge -vq /tmp/foo.img 8m > fs_types for mke2fs.conf resolution: 'ext4', 'huge' > % /bin/rm /tmp/foo.img ; mkfs.ext4 -o hurd -vq /tmp/foo.img 8m > fs_types for mke2fs.conf resolution: 'ext2', 'small', 'hurd' > > Also note that the ext2/ext3/ext4 fs_type will always be in > fs_types[0], so it's not necessary to search the entire list, as the > patch is currently doing: But that's not quite right either: # mke2fs -t small -T ext4 -vqn a.img fs_types for mke2fs.conf resolution: 'small', 'ext4' So to find the 'ext4' here, you /do/ have to iterate the whole list. --D > > > + for (i = 0; fs_types[i]; i++) > > + if (!strcmp(fs_types[i], "ext4")) > > + found_ext4 = 1; > > > Cheers, > > - Ted > > P.S. Although I'm not aware of anyone actually doing this, if there > mke2fs is installed as mke3fs or mke4fs, that's the equivalent of > mkfs.ext3 and mkfs.ext4. (See the logic in the parse_fs_type > function.) Although perhaps there is some obscure distro somewhere > out there that I don't know about....