linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Ernesto A. Fernández" <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
Date: Mon, 3 Sep 2018 09:32:36 +1000	[thread overview]
Message-ID: <20180902233236.GA27618@dastard> (raw)
In-Reply-To: <20180902043309.aa3hcxbe2wsboc2x@eaf>

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

  reply	other threads:[~2018-09-03  3:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31  3:58 [PATCH 1/6] hfsplus: prevent btree data loss on root split Ernesto A. Fernández
2018-08-31  3:59 ` [PATCH 2/6] hfsplus: fix BUG on bnode parent update Ernesto A. Fernández
2018-10-24  1:33   ` Viacheslav Dubeyko
2018-10-24  2:48     ` Ernesto A. Fernández
     [not found]       ` <20181024143947.4e30cca3ddda937db70237e9@linux-foundation.org>
2018-10-24 22:45         ` Ernesto A. Fernández
2018-08-31  4:00 ` [PATCH 3/6] hfsplus: prevent btree data loss on ENOSPC Ernesto A. Fernández
2018-08-31  4:00 ` [PATCH 4/6] hfs: prevent btree data loss on root split Ernesto A. Fernández
2018-08-31  4:01 ` [PATCH 5/6] hfs: fix BUG on bnode parent update Ernesto A. Fernández
2018-08-31  4:01 ` [PATCH 6/6] hfs: prevent btree data loss on ENOSPC Ernesto A. Fernández
2018-08-31  5:36 ` [PATCH 1/6] hfsplus: prevent btree data loss on root split Christoph Hellwig
2018-08-31 14:55   ` Ernesto A. Fernández
2018-09-01  4:49     ` Dave Chinner
2018-09-02  4:33       ` Ernesto A. Fernández
2018-09-02 23:32         ` Dave Chinner [this message]
2018-09-03  0:06           ` Ernesto A. Fernández
2018-09-06 18:28 ` Ernesto A. Fernández
2018-10-24  1:23 ` Viacheslav Dubeyko
2018-10-24  1:32   ` Ernesto A. Fernández
2018-10-25 16:51     ` Viacheslav Dubeyko
2018-10-25 19:42       ` Ernesto A. Fernández
2018-10-26 16:58         ` Viacheslav Dubeyko
2018-10-27  5:15           ` Ernesto A. Fernández

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180902233236.GA27618@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=ernesto.mnd.fernandez@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).