From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:40350 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751169AbdFEALo (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Sun, 4 Jun 2017 20:11:44 -0400
Date: Mon, 5 Jun 2017 01:11:42 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Richard Narron <comet.berkeley@gmail.com>,
        Will B <will.brokenbourgh2877@gmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: UFS s_maxbytes bogosity
Message-ID: <20170605001142.GP6365@ZenIV.linux.org.uk>
References: <CA+55aFwMTzija75vrOs4Gs55QSfLp5SAXPKaDXp__t1OW53XRQ@mail.gmail.com>
 <20170604213736.GM6365@ZenIV.linux.org.uk>
 <20170604215838.GA24416@ZenIV.linux.org.uk>
 <20170604220602.GN6365@ZenIV.linux.org.uk>
 <CA+55aFw6kJ4vc2Gg1dioQ4Rvbx60brS7USbOqL+WE8Q4PEp6pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFw6kJ4vc2Gg1dioQ4Rvbx60brS7USbOqL+WE8Q4PEp6pw@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Jun 04, 2017 at 04:26:51PM -0700, Linus Torvalds wrote:

> So assuming we trust UFS doesn't do that (and considering that it uses
> the default VFS helpers for reading etc, it's presumably all good), we
> might as well just use the MAX_LFS_FILESIZE define.

Umm...  Might start hitting this (in ufs_block_to_path()):
                ufs_warning(inode->i_sb, "ufs_block_to_path", "block > big");

> It's not as if we need to get s_maxbytes exactly right. All we
> *really* care about is to get the LFS case ok for code that is limited
> to 31 bits, and to not overflow the page index when we use the page
> cache (which MAX_LFS_FILESIZE does already).
> 
> Past that, any extra precision can avoid a few unnecessary calls down
> to the filesystem (ie not bother to do extra readpage calls for cases
> we know aren't relevant), but it shouldn't be a big deal.

For UFS2 - yes, for UFS1 we have another hard limit I'd missed.  i_blocks
is in half-kilobyte units there and it's 32bit on-disk.  So for UFS1 I'd
cap it with 1Tb (the real limit is ~ 2Tb - 2Mb, but accurate calculation
is a bit of a bother).  Come to think of that, the minimal block size for
UFS1 is 4K with pointers-per-block >= 1024.  So tree-imposed limit is
no lower than 1024^3*4096, i.e. greater than that and we could make
->s_maxbytes unconditional 1Tb for UFS1.