Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp194556pxt; Wed, 11 Aug 2021 18:26:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdDwfLHHb6ALgq2MyC4k+9R0EFWmhZxwAhYvLEAFWIufWWtaNlvYFAddxcWCgwMWIUn/hN X-Received: by 2002:a6b:6d16:: with SMTP id a22mr1063275iod.209.1628731614329; Wed, 11 Aug 2021 18:26:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628731614; cv=none; d=google.com; s=arc-20160816; b=lVyQuqX6pltyZrMRdtkHVDoWnvV2SrXyI/taWf+wGFXbSBIgoId/D9kYj52zJR4XWc 28gSS+ady0qHOws7q85XnU/dQK+/BMRnEZ7L9uU+YuYn2YFpK5AuyR1k61GmaJySZ38T BVrPUt2WnYwvpJyLS8/+nmhODA9Cu0an15RoxwK1szZzUxYrpz0zCN8khFfg1C0KMNI8 Owvt3RQqMZ58QeAvfmQmCCWp8HWc9y4ndUMjFgvUu5P8waaaRozkS3uIXvzZRHbba/is NahiKw2Di/TGAWcUFPvfjrpJcTsGtur5LndAjOCKbMV+vvy9SOTwFLHnvuwCRTLyBEAP Yizg== 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; bh=sbG9Y5y/I5F9OY/qyEuZsN9JWU5bQ2lbCURC0VhsBJU=; b=dMuTa1s2aJ0lD2NEYXqwVTOk33rrpg/THfsDQmrrnvppAYpoeInagRCUQ9gfcT+uE1 vw5ErfPSrY/tJmTEkxey5UCLEVpgt5cBxpM2YPNdWhtI68OzoSMLM2jWAc/YhvkJLxS+ ydf2X9zNuis5SO3qZ7pDTl68HaJdt/9ASnI6PjVoGxVLHA/UPWwwukGuOtdjMB4Wp2gk 2zsVeQ0BK0eQ0WNrweNJpgHyknc5mxyBnT6/CnrVqDgPVxgcctDzbFDTH9CftXOgpOOh kUBMnl/IAoPjKKmo0lVvdWjhY5kbq7sjUrcQwLvC+kZ66piOLBz9H3w2zdbU5ulNyftZ Dk2A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si1143185jas.83.2021.08.11.18.26.30; Wed, 11 Aug 2021 18:26:54 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233208AbhHLBZw (ORCPT + 99 others); Wed, 11 Aug 2021 21:25:52 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:46857 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S233215AbhHLBZw (ORCPT ); Wed, 11 Aug 2021 21:25:52 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17C1PJKG014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Aug 2021 21:25:19 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id D9F0C15C37C1; Wed, 11 Aug 2021 21:25:18 -0400 (EDT) Date: Wed, 11 Aug 2021 21:25:18 -0400 From: "Theodore Ts'o" To: "Darrick J. Wong" Cc: linux-ext4 Subject: Re: [PATCH] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs Message-ID: References: <20210811233253.GC3601392@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210811233253.GC3601392@magnolia> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 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: % /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: > + 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....