[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87d2utxiqm.fsf@openvz.org>
Date: Thu, 21 Mar 2013 12:25:05 +0400
From: Dmitry Monakhov <dmonakhov@...nvz.org>
To: Jan Kara <jack@...e.cz>
Cc: ext4 development <linux-ext4@...r.kernel.org>,
Jan Kara <jack@...e.cz>
Subject: Re: FYI: one more way to run xfstest
On Wed, 20 Mar 2013 12:28:52 +0100, Jan Kara <jack@...e.cz> wrote:
> On Wed 20-03-13 14:06:05, Dmitry Monakhov wrote:
> >
> > Today I've run xfstest in parallel with fsfreze/fsthaw like follows
> > # I use dmsetup {suspend,resume} which does fsfreeze/fsthaw and other
> > # dm's speciffic stuff (which is not related in that case)
> > (while true ;do dmsetup suspend $TEST_DEV ;dmsetup resume $TEST_DEV;done)&
> > (while true ;do dmsetup suspend $SCRATCH_DEV ;dmsetup resume $SCRATCH_DEV;done)&
> > # And later as usual
> > ./check -g auto
> > I use origin/dev (current dev HEAD): c902ed2d06a
> >
> > Quickly it spots a lot of traces from incorrect freeze-api state:
> > ------------[ cut here ]------------
> > WARNING: at fs/ext4/ext4_jbd2.c:50 __ext4_journal_start_sb+0x132/0x240()
> Heh, funny, Al Viro just found this issue as well yesterday. The problem
> is that ext4_file_dio_write() is missing proper freeze protection. We are
> likely going to somewhat move where freeze protection happens for writes
> due to other issues (discussing that now) so it doesn't make sense to fix
> it just now in ext4.
Ok, Al Viro already has fix for that in his tree.
It is appeared that 068'th test result in interesting bugs because it
use xfs_freeze which call ->freeze_super() (dmsetup suspen usefreeze_bdev() )
I've run in like follows:
(while true ;do dmsetup suspend $TEST_DEV ;dmsetup resume $TEST_DEV;done)&
(while true ;do dmsetup suspend $SCRATCH_DEV ;dmsetup resume $SCRATCH_DEV;done)&
./check 068 068 068 068 068 068 068 068 068 068 068 068
LIST of bugs I know at this moment:
1)
View attachment "1.txt" of type "text/plain" (2626 bytes)
Patch already available here: http://patchwork.ozlabs.org/patch/229377/
2)
View attachment "2.txt" of type "text/plain" (1509 bytes)
Happens because we do do_truncate() but got_write == 0 inside do_last()
I'll send patch soon.
3) This one look's strange and I dont have fix for that for now.
View attachment "3.txt" of type "text/plain" (8273 bytes)
Powered by blists - more mailing lists