From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from ipmail03.adl6.internode.on.net ([150.101.137.143]:42666 "EHLO
        ipmail03.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1726763AbeICDuJ (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Sun, 2 Sep 2018 23:50:09 -0400
Date: Mon, 3 Sep 2018 09:32:36 +1000
From: Dave Chinner <david@fromorbit.com>
To: Ernesto =?iso-8859-1?Q?A=2E_Fern=E1ndez?=
        <ernesto.mnd.fernandez@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
        linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/6] hfsplus: prevent btree data loss on root split
Message-ID: <20180902233236.GA27618@dastard>
References: <26d882184fc43043a810114258f45277752186c7.1535682461.git.ernesto.mnd.fernandez@gmail.com>
 <20180831053642.GA29605@infradead.org>
 <20180831145554.un5pb46m4l74hrvp@eaf>
 <20180901044926.GI1572@dastard>
 <20180902043309.aa3hcxbe2wsboc2x@eaf>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180902043309.aa3hcxbe2wsboc2x@eaf>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Sep 02, 2018 at 01:33:09AM -0300, Ernesto A. Fern�ndez wrote:
> On Sat, Sep 01, 2018 at 02:49:26PM +1000, Dave Chinner wrote:
> > On Fri, Aug 31, 2018 at 11:55:54AM -0300, Ernesto A. Fern�ndez wrote:
> > > On Thu, Aug 30, 2018 at 10:36:42PM -0700, Christoph Hellwig wrote:
> > > > On Fri, Aug 31, 2018 at 12:58:19AM -0300, Ernesto A. Fern�ndez wrote:
> > > > > Creating, renaming or deleting a file may cause catalog corruption and
> > > > > data loss.  This bug is randomly triggered by xfstests generic/027, but
> > > > > here is a faster reproducer:
> > > > > 
> > > > >   truncate -s 50M fs.iso
> > > > >   mkfs.hfsplus fs.iso
> > > > >   mount fs.iso /mnt
> > > > >   i=100
> > > > >   while [ $i -le 150 ]; do
> > > > >     touch /mnt/$i &>/dev/null
> > > > >     ((++i))
> > > > >   done
> > > > >   i=100
> > > > >   while [ $i -le 150 ]; do
> > > > >     mv /mnt/$i /mnt/$(perl -e "print $i x82") &>/dev/null
> > > > >     ((++i))
> > > > >   done
> > > > >   umount /mnt
> > > > >   fsck.hfsplus -n fs.iso
> > > > 
> > > > It would be good to wire up this short reproducer as well for xfstests.
> > > 
> > > Yes, that's my intention. The problem is that mkfs.hfsplus does not allow
> > > setting the size of the filesystem for scratch_mkfs_sized(); you need a
> > > workaround with the device mapper. I think I should submit that patch first
> > > and see if there is a problem with it.
> > 
> > You don't need to do that. We use loop devices like this w/ mkfs_dev
> > quite a lot in fstests. For example, generic/361 has pretty much the
> > exact code pattern you need....
> 
> I see what you mean in this case, but I really want to run every test that
> uses _scratch_mkfs_sized(); generic/027 in particular, since it's the one
> that found these bugs for me.

Trying to hack around SCRATCH_DEV to be some other device set up by
_scratch_mkfs_sized is likely to break things in unexpected ways.
Lots of library routines directly access SCRATCH_DEV or manipulate
it in interesting ways (e.g. build their own dm constructs on it).

IMO the right thing to do is implement the size parameter in
mkfs.hfsplus. I note that it has a dry-run capability (-N <size>)
already allows it to simulate making a filesystem of any size, so it
looks to me that most of what you need it to do is already in the
mkfs code. Then you can test for the mkfs parameter in
_scratch_mkfs_sized....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com