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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 094B4C0650F for ; Thu, 8 Aug 2019 18:28:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D054B217D7 for ; Thu, 8 Aug 2019 18:28:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nByiJIjp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732700AbfHHS2K (ORCPT ); Thu, 8 Aug 2019 14:28:10 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:42312 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbfHHS2K (ORCPT ); Thu, 8 Aug 2019 14:28:10 -0400 Received: by mail-ot1-f66.google.com with SMTP id l15so122504140otn.9; Thu, 08 Aug 2019 11:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JP31KWXxB5g0ATua8LYOvPZ42m/v4rF4TStXnIb5Wjo=; b=nByiJIjprASucnNzVSdLuIdgXtP4B3tGEGEVsOJKICYYa+Fw0MLan8TTtYsjZBIqGS R7ad+Oh3wPEDTxf56rDQ+qLoJr229H524vy3fsjCPnZaGxBuOoDm7f6F9oGhtMwGfWmG F1xsKK3h1vXSZRGnSSgMDiGucJqq1uQcJbveOxTF9jQaTV7dl6Dhil/qkUnL+AN/vnzD gSXr94oJtAXdJ99rbJNlFOBq2yzvAJEtUTWYb8xcfQ2Da0wet6TfBczRhL4I3LiWNfN3 kb8TyLMtSkLsxAXeJJi2cIgYrZTyooUBwfONKqhvEjJ7XWUl6jKqc5IBV4ega6w5DH2m NPYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JP31KWXxB5g0ATua8LYOvPZ42m/v4rF4TStXnIb5Wjo=; b=agtmCJNRPlM8GuV3TgF8TmvP/Nm2Djuc21K6YJk1F14icRr3kvawU+ssoFmiX/GLp9 16lm9w4iemLvjLLND7UPzVZsxNdQ1huwTnaE//XpH1exFPHmHSoKSDUY4KRJGw1Opx+v AalF6MXhIFPh7iarGvUVTUSQLiONTLpkCQ8kWp1AlbZQ8JiQp67JxR/LI5nOockIdTve nBy/IkKkczfkFtCQTBVL9T9l1sd1a6I1OPHJ/a6LCI4bmOc//KLBsIOOxItWA1pW5mwc ulguhfSAVJHutUUtcwpAyuV4CZRnqKX8arD4q+yT96AiTMwPx1Jnu/RMgwpLSC7fVPWS 6SDg== X-Gm-Message-State: APjAAAXI8aBfFMyL0w5guMz0pZdOQb520NXbivd2lPZFjQ1LgqkwU9QC Y2s49liETmXGi1Ip1AJCvRPmcc8tcEH37CZgv0vHh6jD X-Google-Smtp-Source: APXvYqxiT1Fy5xeg3rKlce6LGFT5t1JXKK2E1x1kK9KiqPpRIsArdQ/QFfe9Ql8uS++MitNb7fpHSifTnT5SwGyf9Jk= X-Received: by 2002:a6b:f406:: with SMTP id i6mr16160255iog.110.1565288889403; Thu, 08 Aug 2019 11:28:09 -0700 (PDT) MIME-Version: 1.0 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> <20190803160257.GG4308@mit.edu> In-Reply-To: From: Deepa Dinamani Date: Thu, 8 Aug 2019 11:27:57 -0700 Message-ID: Subject: Re: [PATCH 09/20] ext4: Initialize timestamps limits To: Andreas Dilger Cc: Arnd Bergmann , "Theodore Y. Ts'o" , "Darrick J. Wong" , Alexander Viro , Linux Kernel Mailing List , Linux FS-devel Mailing List , y2038 Mailman List , Ext4 Developers List Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org > Rather than printing a warning at mount time (which may be confusing > to users for a problem they may never see), it makes sense to only > print such a warning in the vanishingly small case that someone actually > tries to modify the inode timestamp but it doesn't fit, rather than on > the theoretical case that may never happen. Arnd and I were discussing and we came to a similar conclusion that we would not warn at mount. Arnd suggested maybe we include a pr_warn_ratelimited() when we do write to these special inodes. In general, there is an agreement to leave the fs granularity to a higher resolution for such super blocks. And hence, the timestamps for these special cases will never be clamped in memory.(Assuming we do not want to make more changes and try to do something like __ext4_expand_extra_isize() for in memory inode updates) We could easily try to clamp these timestamps when they get written out to the disk by modifying the EXT4_INODE_SET_XTIME to include such a clamp. And, at this point we could also warn. If this is acceptable, I could post an update. -Deepa