[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170119233824.10435.qmail@ns.sciencehorizons.net>
Date: 19 Jan 2017 18:38:24 -0500
From: "George Spelvin" <linux@...encehorizons.net>
To: tytso@....edu
Cc: jack@...e.cz, linux-ext4@...r.kernel.org, linux@...encehorizons.net
Subject: Re: Ext4 deadlock (+lockdep splat) during rsync
> 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
Are you referring to some other patches I should be looking for?
> (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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists