Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4134142ybb; Tue, 7 Apr 2020 01:10:54 -0700 (PDT) X-Google-Smtp-Source: APiQypKeQWawzJeZ/5PGS5r0Z/fMAnVt/gW8MNnzbeLHyPjKUv17NOh2mg4sHuzmN0NDoT4O6hhe X-Received: by 2002:aca:5444:: with SMTP id i65mr741297oib.101.1586247054318; Tue, 07 Apr 2020 01:10:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586247054; cv=none; d=google.com; s=arc-20160816; b=OiiHt10LNuqVebeGiBRRFpPrSHqmqH3ONzRWGMTcHkXS+eSZiMbnQvhveMyk/DJODb mCSTm7oZ2RdhogNA8Rqw2nBeAz/5Av7eZMwA168BC8OPMth1dWPo4do125/84kwsbCYS x1QdhtTmBAkO5r+mX2/3Yp3zsRUvl4xey9Ozq08ftQFkBcgIBYALNy+tmDeGvhFtc3ek axKKJ7/BmCi1MwhCulbG1lb5WtS0nsO4QCc4dcaL4FcaJhT4Ut5ahZhWYYFqZX5udwKK slR0lNl15qlBTO+kknFExSwwx0NYGkbUXgwiAnRm78Nm0XnxqGa+Vn9Q/K1FUquDwnO0 DG0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=6KtpwQbHgMdxXm6vDuU03l4OqgNg5eZMVQPDKUtWRFQ=; b=AR0aHAdLwPJ8Of/S8tSf6E5LLrLwXGBd9S6oEQUTHfJwSk3C+sDcJv12p0SsPY9pJj +ODvIyqql00UOc13C5CmOcySHKV8xoUFLWkWxc2BPduoBrKr8iDBSMnXJc14WvZMZhKd Gfnvj++aibOD2g5w1ix4W5lTtV89ydDITovixGPdzQazj+g7+e/lE0KtvvfYyz85+JlR IxHUEkOJb4FLRDbfn6q+DtAOLVYakCMPCYQO3BgEyvMP83/1wNtczXmS/12hyibAsrps FI9v0ph53AX090FZbSN/u0vBQz35WL3RPK9Bdajx8fbIVpfzzct/e6/lle5DE/GYFS1S GFsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u66si368891oib.159.2020.04.07.01.10.37; Tue, 07 Apr 2020 01:10:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726393AbgDGIJc (ORCPT + 99 others); Tue, 7 Apr 2020 04:09:32 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:35125 "EHLO relay10.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726030AbgDGIJc (ORCPT ); Tue, 7 Apr 2020 04:09:32 -0400 Received: from localhost (50-39-163-217.bvtn.or.frontiernet.net [50.39.163.217]) (Authenticated sender: josh@joshtriplett.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 681C724000B; Tue, 7 Apr 2020 08:09:27 +0000 (UTC) Date: Tue, 7 Apr 2020 01:09:25 -0700 From: Josh Triplett To: "Theodore Y. Ts'o" Cc: linux-ext4@vger.kernel.org Subject: Re: Use case for EXT4_INODE_HUGE_FILE / EXT4_HUGE_FILE_FL? Message-ID: <20200407080925.GA675720@localhost> References: <20200406224534.GA668050@localhost> <20200407033031.GT45598@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200407033031.GT45598@mit.edu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Apr 06, 2020 at 11:30:31PM -0400, Theodore Y. Ts'o wrote: > On Mon, Apr 06, 2020 at 03:45:34PM -0700, Josh Triplett wrote: > > Under what circumstances can an inode ever end up with EXT4_HUGE_FILE_FL > > set? (Other than in an artificially constructed filesystem.) > > > > Was EXT4_HUGE_FILE_FL just added for future extensibility, in case a > > future file storage mechanism allows storing files bigger than 2**32 > > blocks? > > Yes. basically. When we added the huge_file feature, which introduced > the i_blocks_hi field, the thinking was to add EXT4_HUGE_FILE_FL so > that we could painlessly upgrade a file system from ext3 (w/o the huge > file feature) to enabling the feature without having to rewrite all of > the inodes. However, we also didn't want to artificially limit > ourselves to 2**57 file sizes, so we also added the EXT4_HUGE_FILE_FL > flag. Thanks for the explanation! That makes sense. > It hasn't gotten a huge amount of testing in a while, but it would be > relatively easy to add debugging code (triggered via a mount option or > a sysfs file) which forces the use of EXT4_HUGE_FILE_FL all the time. That does seem like a good idea. It would also be nice to have an e2fsck option to rewrite all inodes to use EXT4_HUGE_FILE_FL. I think I'll avoid poking that code for now, though, since I don't currently have a need for files anywhere near that large.