From: Dave Chinner <david@fromorbit.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: __sb_start_write() && force_trylock hack
Date: Wed, 19 Aug 2015 13:25:26 +1000 [thread overview]
Message-ID: <20150819032526.GP714@dastard> (raw)
In-Reply-To: <20150818151816.GA27851@redhat.com>
On Tue, Aug 18, 2015 at 05:18:16PM +0200, Oleg Nesterov wrote:
> On 08/18, Oleg Nesterov wrote:
> >
> > When I tried to run all tests, I
> > got the new reports from lockdep.
>
> Just in case... when I run all tests I see misc failures (with or without
> the changes above) which I didn't try to interpret. In particular xfs/073
> just hangs, "shutdown -r" doesn't work, the serial console continues to
> print
>
> [10784.605139] XFS (loop2): metadata I/O error: block 0x7d4948 ("xfs_buf_iodone_callbacks") error 5 numblks 8
EIO from the loop device.
> [10784.605207] loop: Write error at byte offset 26843578368, length 4096.
> [10784.605222] loop: Write error at byte offset 26843578368, length 4096.
> [10784.605235] loop: Write error at byte offset 26843578368, length 4096.
> [10784.605248] loop: Write error at byte offset 26843578368, length 4096.
> [10784.605261] loop: Write error at byte offset 26843578368, length 4096.
That makes me think the underlying filesystem (i.e. the fs the loop
image file is hosted on) ran out of space. Everything will go to
shit if that happens.
> again and again.
>
> Plus some tests need a lot of time (for example generic/127 more than 70 minutes!),
Yup, that one only does about 50,000 synchronous writes via fsx.
If you want to run fast, use a virtual machine with 10GB RAM and use
a pair of 4GB ramdisks as the storage.
Or expunge the long running tests (look up the -X option) so they
are skipped.
> Also, tests/generic/078 on 4.2.0-rc6 (without other changes) triggered
>
> [ 2100.404545] BUG: looking up invalid subclass: 8
> [ 2100.409600] turning off the locking correctness validator.
That's another lockdep annotation limitation I've had to work
around. The RENAME_WHITEOUT changes caused that by introducing the
need to lock 5 inodes at the same time (src/dst dir, src/dst file,
whiteout inode) instead of only 4.
> perhaps this was fixed by Dave's ILOCK patches.
It greatly complicated those patches, you mean?
But, yes, those patches should have fixed it - I had to shoehorn
about 15 different XFS inode locking subclasses into the 8
subclasses that lockdep supports. And I used all 8 subclasses for
the ILOCK annotations, so if theres some other annotation we need to
add (e.g more than one level of ILOCK_PARENT lock nesting) then,
well, we will need at least 16 subclasses to annotate everything.
I hate lockdep.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2015-08-19 3:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 14:49 __sb_start_write() && force_trylock hack Oleg Nesterov
2015-08-18 15:18 ` Oleg Nesterov
2015-08-19 3:25 ` Dave Chinner [this message]
2015-08-19 3:11 ` Dave Chinner
2015-08-19 15:00 ` Oleg Nesterov
2015-08-19 23:26 ` Dave Chinner
2015-08-21 18:30 ` Oleg Nesterov
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=20150819032526.GP714@dastard \
--to=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
/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).