linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: George Spelvin <linux@sciencehorizons.net>
Cc: jack@suse.cz, linux-ext4@vger.kernel.org
Subject: Re: Ext4 deadlock (+lockdep splat) during rsync
Date: Fri, 20 Jan 2017 09:40:26 -0500	[thread overview]
Message-ID: <20170120144026.bvg2mpe3uvb5yspi@thunk.org> (raw)
In-Reply-To: <20170119233824.10435.qmail@ns.sciencehorizons.net>

On Thu, Jan 19, 2017 at 06:38:24PM -0500, George Spelvin wrote:
> > I think the inline_data patches I posted should have taken care of
> > George's initial set of bug reports?
> 
> Er, the two I posted most recently were on a kernel with your 4-patch
> deadlock series applied:
> 
> 98a9e36a ext4: propagate error values from ext4_inline_data_truncate()
> 50c39f0d ext4: avoid calling ext4_mark_inode_dirty() under unneeded semaphores
> f321034b ext4: fix deadlock between inline_data and ext4_expand_extra_isize_ea()
> 5283ac14 ext4: add debug_want_extra_isize mount option

Yes, I know that's why I said, it takes care of the _initial_ set of
bug reports (not your recently reported ones).  Jan's comments
indicated he was lookig at the initial set, and I to avoid him redoing
work that i had already done.

Those bugs look like they are very separate in that they have nothing
to do with locking, but rather in e2fsck and the kernel not properly
dealing with certain types of inconsistencies on disk.  On my list to
deal with.  As a workaround, you can just clri the offending corrupted
inode from lost+found and then run e2fsck.

> > (And George, the reason why you're seeing lots of problems is because
> > inline_data isn't enabled by default yet, and as the old joke goes,
> > the Early Christians get the best Lions.  :-)
> 
> Yes, I know I'm tempting fate by keeping data I actaully care about (I
> have backups of most of it, but reassembling it from those backups would
> be most unpleasant) on a file system with experimental features enabled.
> 
> But *somebody* has to debug new features, and I've noticed that the fickle
> goddess Glitch is most likely to make an appearance when She sees such
> an offering.

Indeed, the reason why we didn't see this earlier is because we don't
have a test which tests the case of expanding i_extra_size with inline
data, and the introduction of project quota was the first time we've
expanded the extra inode fields in a while.  Since you were using
inline_data, you very graciously exposed these bugs and a shortcoming
in our testing.  :-)

On my todo list is to add some i_extra_isize testing to xfstsests.

      	   	      	       		     - Ted

  reply	other threads:[~2017-01-20 14:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-08 22:41 Ext4 deadlock (+lockdep splat) during rsync George Spelvin
2017-01-10  3:40 ` Theodore Ts'o
2017-01-10  7:25   ` George Spelvin
2017-01-19 17:37 ` Jan Kara
2017-01-19 17:45   ` Jan Kara
2017-01-19 17:59     ` George Spelvin
2017-01-19 23:19   ` Theodore Ts'o
2017-01-19 23:38     ` George Spelvin
2017-01-20 14:40       ` Theodore Ts'o [this message]
2017-01-20 17:57         ` George Spelvin
2017-01-21 13:30           ` Theodore Ts'o
2017-01-21 16:45             ` ext4_iget:4740: inode #%ld: block 48: comm find: invalid block George Spelvin
2017-01-23  0:08               ` Theodore Ts'o

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=20170120144026.bvg2mpe3uvb5yspi@thunk.org \
    --to=tytso@mit.edu \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux@sciencehorizons.net \
    /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).