From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CBBBC31E40 for ; Sat, 3 Aug 2019 16:03:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7189420679 for ; Sat, 3 Aug 2019 16:03:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387769AbfHCQDR (ORCPT ); Sat, 3 Aug 2019 12:03:17 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:50491 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387464AbfHCQDR (ORCPT ); Sat, 3 Aug 2019 12:03:17 -0400 Received: from callcc.thunk.org ([199.116.115.135]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x73G2wIF010152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Aug 2019 12:03:00 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id DE3914202F5; Sat, 3 Aug 2019 12:02:57 -0400 (EDT) Date: Sat, 3 Aug 2019 12:02:57 -0400 From: "Theodore Y. Ts'o" To: Arnd Bergmann Cc: Deepa Dinamani , "Darrick J. Wong" , Alexander Viro , Linux Kernel Mailing List , Linux FS-devel Mailing List , y2038 Mailman List , Andreas Dilger , Ext4 Developers List Subject: Re: [PATCH 09/20] ext4: Initialize timestamps limits Message-ID: <20190803160257.GG4308@mit.edu> Mail-Followup-To: "Theodore Y. Ts'o" , Arnd Bergmann , Deepa Dinamani , "Darrick J. Wong" , Alexander Viro , Linux Kernel Mailing List , Linux FS-devel Mailing List , y2038 Mailman List , Andreas Dilger , Ext4 Developers List References: <20190730014924.2193-1-deepa.kernel@gmail.com> <20190730014924.2193-10-deepa.kernel@gmail.com> <20190731152609.GB7077@magnolia> <20190801224344.GC17372@mit.edu> <20190802154341.GB4308@mit.edu> <20190802213944.GE4308@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 03, 2019 at 11:30:22AM +0200, Arnd Bergmann wrote: > > I see in the ext4 code that we always try to expand i_extra_size > to s_want_extra_isize in ext4_mark_inode_dirty(), and that > s_want_extra_isize is always at least s_min_extra_isize, so > we constantly try to expand the inode to fit. Yes, we *try*. But we may not succeed. There may actually be a problem here if the cause is due to there simply is no space in the external xattr block, so we might try and try every time we try to modify that inode, and it would be a performance mess. If it's due to there being no room in the current transaction, then it's highly likely it will succeed the next time. > Did older versions of ext4 or ext3 ignore s_min_extra_isize > when creating inodes despite > EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE, > or is there another possibility I'm missing? s_min_extra_isize could get changed in order to make room for some new file system feature --- such as extended timestamps. That's how we might take an old ext3 file system with an inode size > 128, and try to evacuate space for extended timestamps, on a best efforts basis. And since it's best efforts is why Red Hat refuses to support that case. It'll work 99.9% of the time, but they don't want to deal with the 0.01% cases showing up at their help desk. If you want to pretend that file systems never get upgraded, then life is much simpler. The general approach is that for less-sophisticated customers (e.g., most people running enterprise distros) file system upgrades are not a thing. But for sophisticated users, we do try to make thing work for people who are aware of the risks / caveats / rough edges. Google won't have been able to upgrade thousands and thousands of servers in data centers all over the world if we limited ourselves to Red Hat's support restrictions. Backup / reformat / restore really isn't a practical rollout strategy for many exabytes of file systems. It sounds like your safety checks / warnings are mostly targeted at low-information customers, no? - Ted