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]:55698 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751433AbdFHCVA (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 7 Jun 2017 22:21:00 -0400
Date: Thu, 8 Jun 2017 03:20:57 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Richard Narron <comet.berkeley@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Will B <will.brokenbourgh2877@gmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Evgeniy Dushistov <dushistov@mail.ru>
Subject: Re: UFS s_maxbytes bogosity
Message-ID: <20170608022057.GX6365@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>
 <20170605001142.GP6365@ZenIV.linux.org.uk>
 <CA+55aFzbLrVn0p6a7MSYzPK+PsL5TpofDMoxyrtZW5mZSkukBg@mail.gmail.com>
 <20170605034936.GQ6365@ZenIV.linux.org.uk>
 <20170607234837.GA20362@ZenIV.linux.org.uk>
 <alpine.LNX.2.21.1706071729520.1644@joy.test>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LNX.2.21.1706071729520.1644@joy.test>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Jun 07, 2017 at 05:35:31PM -0700, Richard Narron wrote:

> I am willing to test.  I just turned on UFS_FS_WRITE for the very first time
> running 4.12-rc4 and was able to copy a file of more than 2GB from one r/o
> FreeBSD subpartition to another r/w FreeBSD subpartition.
> 
> So it is already looking pretty good.

The nasty cases are around short files, especially short files with holes.
Linear writes as done by cp(1) will do nothing worse than bogus i_blocks
(and possibly mangled counters in cylinder groups).  Random write access
to short files, OTOH, steps into a lot more codepaths...

As for ->i_blocks, it triggers this:

root@kvm1:/mnt# df .; mkdir a; rmdir a; df .
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop0        507420  4504    462340   1% /mnt
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/loop0        507420  4536    462308   1% /mnt

Note the 32Kb (== one block on that ufs2) leaked here.
Every iteration will leak another one.  Similar for long
symlinks...