Re: UFS s_maxbytes bogosity

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Jun 04, 2017 at 08:00:26PM -0700, Linus Torvalds wrote:
> On Sun, Jun 4, 2017 at 5:11 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > 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.
> 
> The nblocks limit (and the 32-bit block numbers) might not limit a
> sparse file, so I think the tree-imposed limit might be the final true
> limit even on UFS1, no?

Yes, but... where would we notice that overflow on allocation?  Matter of fact...
<looks>
<starts swearing>
commit 8f45c33decf62e1aaaa9411aae8fef6a38f95845
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 20 16:00:36 2010 +0200

    ufs: Remove dead quota code
    
    UFS quota is non-functional at least since 2.6.12 because dq_op was set
    to NULL. Since the filesystem exists mainly to allow cooperation with Solaris
    and quota format isn't standard, just remove the dead code.
    
    CC: Evgeniy Dushistov <dushistov@mail.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
<swears some more>

Jan?  You do realize that "non-functional" or not, dquot_alloc_block() updates
->i_bytes/->i_blocks, right?  And removing that should've had the updates put
back explicitly...

Grrr...  OK, I'll put together a patch fixing that idiocy.  As it is, rw mounts
of ufs on-disk ->i_blocks not updated and, AFAICS, can lead to disk space leaks
on inode deletion.